(Forgot to reply to all)
--- Begin Message ---
- Subject: Re: Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 04 Jun 2019 13:45:42 +0200
>>> Michael Chapman <mike@xxxxxxxxxxxxxxxxx> schrieb am 04.06.2019 um 11:04 in Nachricht <alpine.LFD.2.21.1906041855390.3180@xxxxxxxxxx>: > On Tue, 4 Jun 2019, Ulrich Windl wrote: >> >>> Michael Chapman <mike@xxxxxxxxxxxxxxxxx> schrieb am 03.06.2019 um 13:14 in >> Nachricht <alpine.LFD.2.21.1906032106200.3180@xxxxxxxxxx>: >> [...] >> > >> > Um, OK. I don't think we're any closer to solving your problem though. :‑) >> >> Actually I am! >> The root of the problem is that any oneshot service without >> RemainAfterExit=true is listed as "inactive (dead)" after being started. >> I think the manual page should be more clear on that fact! Then if you >> have a dependency like this (best viewed with a monospaced font): >> B >> / \ >> A‑C‑E >> \ / >> D >> >> where A is a target that wants B,C,D, and each of those in turn wants E >> (which is the oneshot service), the following happens: When starting A, >> E is NOT started ONCE, but it is started THREE TIMES, while my >> expectation was it will be started once only. As I had set a burst limit >> of 1, an unexpected fauilure was reported. >> >> What I'm unsure: Does systemd wait for each "start of E" to terminate >> before calling the next one (i.e. serialized), or are the starts being >> attempted in parallel? >> >> The obvious deficit in systemd is that it does not no a proper 2‑pass >> dependency analysis before executing: If it would do a dependency >> analysis for starting A, it would see that E has to be started ONCE >> before B,C,D. In stead it seems to do a 1‑pass analysis firing the start >> of E every time. > > This doesn't seem right to me, as systemd _does_ have the concept of > transactions to which multiple jobs can be attached, and the set of jobs > does appear to be determined in one go based upon the configured > requirement dependencies. > > So I thought I'd set up a test case. I created a set of Type=oneshot units > with Wants= dependencies as in your diagram. There were no ordering > dependencies (Before= or After=). Each service just echoed its own name. > > Then: > > $ systemctl ‑‑user daemon‑reload > $ systemctl ‑‑user start A.service > > yielded: > > systemd[2312]: Reloading. > systemd[2312]: Starting B... > systemd[2312]: Starting D... > echo[21672]: B > systemd[2312]: Starting E... > echo[21673]: D > systemd[2312]: Starting A... > echo[21674]: E > systemd[2312]: Starting C... > echo[21675]: A > systemd[2312]: Started B. > systemd[2312]: Started D. > echo[21676]: C > systemd[2312]: Started E. > systemd[2312]: Started A. > systemd[2312]: Started C. > > As you can see, even E.service was only started once. > > Are you sure you were actually doing everything in one transaction? I guess your version is significantly newer than 228. In 228 I have some odd effects hard to explain (I'm still trying to learn). As far as I can tell the following commands were issued (during package upgrade): reenable E start E reenable A restart A Regards, Ulrich
--- End Message ---
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
