The road forward for systemd
Posted May 27, 2010 9:58 UTC (Thu) by Tobu
In reply to: The road forward for systemd
Parent article: The road forward for systemd
I have RTFA (thanks for the precise quote), and I don't think you get my point.
You have three services: A, B, and C. C depends on B, B depends on A.
The user wants C started.
systemd can rely on socket activation only; it starts C, then B by socket activation, then A by socket activation. Socket activation is convenient because you don't have to declare dependencies. But it is no faster than what upstart would do; upstart would start A, wait for the A-listening event, start B, wait for B-listening event, start C.
Or systemd can have the dependencies encoded; in which case, when C is requested, systemd will know to start A, B and C simultaneously, and the services will block on each other's sockets. This is faster, but you do need to do the work of writing down the dependencies.
So systemd can be faster or easier than other inits. This is not bad at all; one just can't claim that systemd is both faster and dependency-agnostic.
to post comments)