(Forgot to reply to all)
--- Begin Message ---
>>> Michael Chapman <[email protected]> schrieb am 04.06.2019 um 11:04 in
Nachricht <[email protected]>:
> On Tue, 4 Jun 2019, Ulrich Windl wrote:
>> >>> Michael Chapman <[email protected]> schrieb am 03.06.2019 um 13:14
in
>> Nachricht <[email protected]>:
>> [...]
>> >
>> > 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
