[HEADS-UP] systemd for F14 - the next steps

[Lennart Poettering]

On Thu, 22.07.10 09:13, Chris Adams (cmadams at hiwaay.net) wrote:

> IMHO, systemd seems to cram a bunch of existing things (init, inetd,
> chkconfig, service, pstree, etc.) together, and the assumption is that
> this is new and good. I don't really agree.  For example, if on-demand
> activation for socket-based services is the way to go, why has everybody
> abandonded that model by moving away from inetd?  Having init directly
> manage services came before sysVinit (hello /etc/inittab), but nobody
> uses that anymore either.

For starters, systemd is not really about on-demand starting of
services. Only very few services in the end will be started
on-demand. Socket activation is awesome for four reasons, only one of
them being that you actually implement on-demand spawning of daemons, if
you wish to.

1. Parallelization: we can completely get rid of any serialization of
startup. We can start *every* signle daemon at the same time in one big
step, regardless whether one of them needs another. i.e. we can start
avahi at the same time as dbus at the same time as syslog at the same
time as nscd, although every single one of them might want to connect to
another one in this list and in traditional thinking they hence would
have needed to be started one after the other, so that every service
using another services can be sure it can talk to the one it needs. I
mean, how awesome is that? We can completely remove *any* kind of
serialization from daemon startup.

2. Simplicity: dependencies become redundant. Nowhere you really have to
declare that avahi requires dbus or dbus requires syslog the way we
currently do in the LSB init script headers: because the sockets will be
established during early boot. All of them. And if some service wants to
talk to them he can just do so, without any explicit dependency
configured. How awesome is this? We can complete remove *any* kind of
declaration of dependencies from daemon startup!

3. Robustness: The sockets stay around all the time, and always
connectable. You can kill a daemon but you won't lose a single
connection while doing that! Particularly for stateless protocols (such
as DNS or syslog) we can automatically restart a daemon when it crashes,
and when it comes back it will go on where it left of, as if nothing
happened! The client will not even notice! How awesome is that?
Restarting daemons without losing connections? 

4. On-Demand Startup: Yes, this too. But this actually is relevant for a
a select few daemons, where it is likely that they aren't used during
boot anyway. If a daemon willk be clearly used during bootup it is smart
to start it as early as possible, and not as late as possible because
then the first user would have to wait for it which prolongs not
shortens the boot process. The select few daemons which can benefit from
on-demand starting is stuff like SSH or CUPS which in most installations
is used seldomly only. But even if we do on-demand by default for these
admins can still start them unconditionally during boot if they want,
simply by placing a single symlink.

Anyway, these four features of socket based activation are what make it
so great. Reducing the whole logic to "inetd in an init system" is
completely besides the point, because it's actually completely unlike
it. While we do socket passing we do it for different reasons and in a
different way. We support inetd compatibility, but in general things will be
different from classic inetd setups in so many ways.

Anyway, I have tried to explain this many times before. For example in
my long blog story. I know I sound like a broken clock, but I can only
encourage people ro read it. http://0pointer.de/blog/projects/systemd.html

Note that this scheme is not new. launchd championed it. It is part of
Apple MacOS since a while.  So if you ask "why has every body abandoned
that model" then this is a completely bogus statement. Because MacOS
just recently moved to it, fully and completey, all over the board.

Please, read my blog novel. It is long. But in it I actually try in
lengths to explain what is so great about systemd. 

Yes, really grokking the greatness of socket based activation actually
takes a while. But try to wrap your head around it. You might enjoy this
talk from an Apple Engineer which explains the logic. It's about
launchd, not systemd. But the socket based activation is similar in both
systems. So listen to it with a grain of salt:

http://video.google.com/videoplay?docid=1781045834610400422#

> Also, hasn't starting lots of services in parallel been tried before and
> found to thrash the system, actually slowing down boot instead of
> speeding it up?

Well, if the IO scheduler cannot cope with it (and indeed it seems it is
not perfoming as well as it should), then this needs to be fixed in the
IO scheduler. In general an elevator should benefit from having a
larger set of requests to choose from.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.