The road forward for systemd [LWN.net]

The road forward for systemd

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

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 (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).
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 (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.

Why it's so hard to understand?

Posted May 27, 2010 7:28 UTC (Thu) by khim (subscriber, #9252) [Link]

I've had this discussion so many times and I still can't believe people are thinking like that. Guys, OR and XOR are different operations! Please open the logic textbook and read about difference between them! This is vital if you want to talk about systemd!

Either implicit dependencies are used, and you rely on socket activation, but you don't start daemons as early as they could be

This perfect illustration: systemd can do A or B, ok, but since if you do A (but don't do B) you need to do this and if you do B (but not do A) you need to do that - and you so are doing neither this nor that so how can that work? Of course in reality systemd can do "A (activate service via socket) or B (start services from the list) and that means it can do A and B simultaneously! Terrific, uber-uncomprehensible idea, isn't it? Implicit dependencies are used and you start daemons as early as possible (i.e.: you start all daemons in parallel). If daemon A needs deamon B it does not mean daemon B should be started earlier - it means daemon A will start first and then will wait for daemon B activation. This will start the system in fastest time possible.

It's all explained in original paper. I know, I know, majority of population can not even imagine OR operation and only think about XOR (they call it OR, of course) - but these people shouldn't discuss design of systemd, that's all.

Why it's so hard to understand?

Posted May 29, 2010 0:25 UTC (Sat) by baldridgeec (guest, #55283) [Link]

I've had this discussion so many times and I still can't believe people are thinking like that. Guys, OR and XOR are different operations! Please open the logic textbook and read about difference between them! This is vital if you want to talk about systemd!
Either implicit dependencies are used, and you rely on socket activation, but you don't start daemons as early as they could be

I haven't done enough thought experiments or study of the init process limitations to have any kind of coherent input about systemd's particulars (despite having read Lennart's blog post with interest last week), but I do have a rather decent knowledge of linguistics in general, and English in particular.

"Either" is a word which introduces a parameter to the conditional expressed by "or." It is a flag which notifies the reader that the first and second clauses of the conditional are mutually exclusive.

In other words:

("OR" != "XOR") == 1

but also

("XOR" == "Either..or") == 1

Why it's so hard to understand?

Posted Jun 4, 2010 23:37 UTC (Fri) by Wol (guest, #4433) [Link]

"Either" (in normal English usage) does *not* imply the two sides of the "or" are exclusive.

"You can borrow my car if you do either A or B" - in other words I don't care which you do and you could do both if you wish. "either" is a filler word which implies "xor" but doesn't require it. If you *really* mean XOR, you have to say "either but not both".

Cheers,
Wol

Why it's so hard to understand?

Posted May 29, 2010 0:30 UTC (Sat) by baldridgeec (guest, #55283) [Link]

I just re-read your post and I think I misunderstood it the first time.

Sorry for the pedantic tone in my previous comment! I guess I get a thrill from taking the wind out of grammar Nazis' sails when they're wrong, but you were addressing a different concern (and you're correct, as far as I understand the process.)