thx for the answer.

> Why not start the final sub-tree units the conventional way, but make
> them all wait, listening on sockets?    A final service need not
> contain a 'systemctl start xxx.target' command, as instead it could
> simply write a message to those sockets.  Some services could receive a
> signal telling them to terminate, and others telling them to continue.

Ok good idea. But finally this is (effort wise) the same like calling systemctl 
(kick off one process, which communicates via IPC with another one). If it is 
now my own socket or the systemd control socket does not really matter.
> Given that it's possible to specify the startup service in the kernel
> command line with "system.unit=",  the engineer configuring the startup
> sequence could specify a variety of alternate dependency
> trees.    Each tree would have a different unit at its head.    The
> units in one tree need not appear in another at all, or they could
> appear in the second tree in a different order.

That's possible as well but might get a bit too complex for a bit more 
dynamics. This finally depends probably on the actual use case.

Ok I guess what I learned from your answers now is that the systemctl approach 
is probably the best one for my concrete use case. Thx all for sharing your 

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948
systemd-devel mailing list

Reply via email to