[systemd-devel] how to support strict ordering going up and down?

[Nekrasov, Alexander]

Take the following structure:

A.service:
Requires=base.service
Type=fork
Restarts=no

B.service:
Requires=base.service
Type=fork
Restarts=no
After=A

C.service:
Requires=base.service
Type=fork
Restarts=no
After=B

Up.target:
Requires=A B C

Normally, systemctl start up.target brings up base, A, B, C, in the correct order. Similarly, systemctl stop base.service brings down C B A, in correct order. All is well.


1)      If A or B fails to start (return 1 from ExecStart), they assume Active: failed state, but the stack continues to start regardless. I expected that Requires= would mean that up.target would stop and start-up would be interrupted. How can I achieve that? Adding up.target::Requisite=A B C doesn't change anything.



a.      This is a simplified example. In reality I have tens of components that only know their immediate dependency, but not the whole chain. Adding explicit C::Requires=B would solve this for when B fails, but imagine there's an F::After=E where F must not Require=E (i.e., F must not stop if E fails), then such F will start even if B failed to start.  So I would have to add a F::Requires=B, and propagate that through the entire stack. And then do the same to A and C, etc. Doesn't seem very scalable or flexible.



2)      If b fails, and then later I stop the base service, shutdown is out of order. C and A stop in parallel, or even C stops after A. It seems like breaking the chain anywhere in the stack breaks the dependency tree at least in that place. In other words, ordering C->B->A doesn't mean translate into C->A if B fails before stopping is initiated. How can I fix that?

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150901/0614c518/attachment.html>