| |||||||||||||
The road forward for systemdThe road forward for systemdPosted May 27, 2010 9:58 UTC (Thu) by Tobu (subscriber, #24111)In reply to: The road forward for systemd by dmk 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.
(Log in to post comments)
The road forward for systemd Posted May 27, 2010 11:34 UTC (Thu) by dmk (subscriber, #50141) [Link]
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).
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,
Does this make any sense?
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.
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.
|
|||||||||||||