The road forward for systemd [LWN.net]

The road forward for systemd

Posted May 27, 2010 11:34 UTC (Thu) by dmk (subscriber, #50141)
In reply to: The road forward for systemd by Tobu
Parent article: The road forward for systemd

Yeah sorry, i didn't pay enough attention, it seems.

Anyway, systemd doesn't encode the dependencies, as far as I understand. So it's advantage over upstart is, that it is faster only, because it does not wait for the full service to start.

A starts up until it reads from socket B (which blocks A).
B starts up until it reads from socket C (which blocks B).

Now either A got unblocked by now, in which case the new scheme is faster, because A can continue even if B isn't startet fully up already,
Or both A and B block on socket C right now. In which case it would be roughly the same as starting all three in a row.
Except that A and B only block until C reads from it's socket. So there is a little bit time saving. But I don't think this is what systemd is about.

Does this make any sense?

(Log in to post comments)

The road forward for systemd

Posted May 27, 2010 11:48 UTC (Thu) by dmk (subscriber, #50141) [Link]

ah, and of course, you probably can specify which services you want to start upon system boot. in which case they get started parallel and only block on each other (worst case) until the slowest system-service has read from it's socket.

So you are right, there is a list of services to start.

The road forward for systemd

Posted May 27, 2010 13:06 UTC (Thu) by Tobu (subscriber, #24111) [Link]

Yes. There are a few way to declare dependencies, some that allow the runtimes to overlap. Here is a good explanation.

There ought to be a way to record which service triggers socket activation and use it to help write dependencies, someone should write that.

The road forward for systemd

Posted May 31, 2010 15:51 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

Yes, we already thought about a way to save the set of started services after boot-up to make the next boot-up even faster. We'll have to play around with this and if it is worth it for perfomance improvements it might bring.