The road forward for systemd

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

Actually the article does explain this in the section "Putting it All Together: systemd".

There are different types of entities systemd is aware of.
The "service" unit and the "socket" unit are what describes the interface to a daemon. Each socket description needs a matching service description.

A daemon then connects to a socket, and systemd blocks that connection until the corresponding service is started and then hands off the socket to that daemon (there comes the patching into play).

So there is no big list needed at all.

Cheers,
Flo

The road forward for systemd

Posted May 27, 2010 9:58 UTC (Thu) by Tobu (subscriber, #24111) [Link] (5 responses)

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.

The road forward for systemd

Posted May 27, 2010 11:34 UTC (Thu) by dmk (guest, #50141) [Link] (3 responses)

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?

The road forward for systemd

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

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] (1 responses)

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.

The road forward for systemd

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

Well, the idea is that services that are anyway required during boot-up are started in one big step, without waiting until they are actually used.

Example: we know that syslog is used by almost all services, hence we start it right-away, and don't wait until somebody actually connects to it.

Also, we distinguish ordering and requirement dependencies. So if you have a service A and one that is needed by it B and neither of them are really needed at bootup you can define a dependency of type "Requires" between them. That will then have the effect that both are started at the same time if they are requested, and the ordering is then again handled by the socket activation logic/the kernel.

So, to make this clear, and repeating what the original blog story explained: we support dependencies just fine, though for the usual services you won't need them. They will be necessary only for a few selected services, in particular a few ones that are needed during early boot-up and late shut-down.