[systemd-bugs] [Bug 85746] Required units are not started in certain setups

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85746

Lennart Poettering <lennart at poettering.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Lennart Poettering <lennart at poettering.net> ---
systemd's dependency logic is fully parallel, and it will dispatch and complete
jobs as early as possible (i.e. eagerly), looking at them individually and
independently of anything else. With a setup like yours, if D.device appears,
then this is all systemd was asked to wait for, and it will complete the job
waiting for it so that this dependency for S1 is fulfilled. The fact that D
goes away immediately afterwards is not relevant for this case.

Also not the distinction between Requires= and BindTo=. Requires= just means
that the the start job of some other unit has to have completed successfully,
and if it didn#t any start job for your unit would fail too. The start job of
units doesn't necessarily result in a unit being active though. For example,
all services of type=oneshot and RemainAfterExit=no generally go from
activating directly into inactive, with the start job being completed
sucessfully. Now, BindTo= is like Requires= but it has one additional effect:
when the specified other unit goes down, your unit will be pulled down too
again, it's hence not only about starting, but also about stopping.

That said, BindTo= is not going to make you happy either I fear, since it#s not
really useful here, because things will be executed in parallel, and hence the
effect of BindTo= pulling your service down is likely to hit your service at a
time where it already started up and failed.

My suggestion for a workaround would be to readd the D.device job a second
time, from s2.service. if the loop device showed up for the the first time, the
D.device is properly completed by systemd. However, after removing the device
again you enqueue the job a second time, so that it needs to be processed by
systemd a second time. For this, you could add ExecStart=/usr/bin/systemctl
start --no-block dev-loop0.device from s2.service, after the two losetup
commands...

Anyway, other than this work-around I cannot suggest much. The state engine
tries to eagerly process jobs, to make things as quick as possible, and it is
simply not compatible with what you are trying to do. Sorry!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20141205/b57246ce/attachment.html>