Отправлено с iPhone

> 1 сент. 2015 г., в 21:39, Nekrasov, Alexander <[email protected]> 
> написал(а):
> 
> 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.

There is no Requires dependency between A, B and C. So up.target will fail 
(because one of required units failed) but it does not affect what happens to 
A, B or C.


> How can I achieve that?

If B requires A it has to say so.

> 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?

If C can start without B being present it is logical to assume that it does not 
need anything before B. If C Required B, described situation would not be 
possible at all.


>  
> Thanks,
> Alex
> _______________________________________________
> systemd-devel mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to