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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
