systemd: please stop trying to take over the world :)

[Lennart Poettering]

On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk at redhat.com) wrote:

>                 kmod_setup();  <=== ???

We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

>                 hostname_setup(); <=== ???

We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a separate
binary is just absurd. This way we also can ensure that the hostname is
always initialised which is very useful for early boot logging and other
stuff. On systemd you get the guarantee that the hostname is always set
up if you run in userspace, among other things (for example, the
loopback device is always set up, you can always bind to 127.0.0.1 and ::1).

>                 machine_id_setup(); <=== ???

Similar to the hostname we ensure that the machine id is always
initialized, and has the same lifetime and validity guarantees as the
hostname. i.e. that it is simply usable by *every* process started,
regardless when.

> "plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

> This is an antithesis to modular, Unix way of doing things.

Just because you can turn each trivial operation into a separate binary
you shouldn't necessarily do that. It is what makes your system slow and
heavy-weight. Insisting that we invoke sethostname() in a separate
process is just stupid. I am mean, come on, think about it. It is *ONE*
system call to the the hostname with sethostname(). Invoking
/bin/hostname instead is at least 40 or so (and many of those quite
heavy weight). And really, why are we even discussing the frickin
hostname like this?

And invoking the plymouth update tool after each process we start
practically doubles the amount of processes we have to spawn. Which is a
great way to make things slow, little more.

> It starts to have shadows of monolithic Windows-like
> "we know better than you what you need" approach.

OMG! You used the "W"-word!

Do you know what "mono" means? It's greek and means "one". And "lithic"
means "stone". And if systemd communicates with Plymouth, then this is
not monolothic at all, since systemd and ply are two processes, not
one. 

systemd is not running Plymouth stuff in the same process, is it merely
communicating with it. And the communication is very very
trivial. 

> hostname_setup()?
> machine_id_setup()? Why systemd has *source-code-level knowledge*
> about it? I would say that if admin wants to have /etc/machine-id,
> he can set up startup code to generate it.

Well, the point is to offer the machine id unconditionally, so that apps
can start relying on them and stop misuing the hostname for stuff they
shouldn't use it for.

> kmod_setup() loads autofs4, ipv6 and unix modules.
> Why? What if I don't want to run automounter?

systemd supports .automount units, and to make that work we need to load
the autofs kmod, if it is not compiled in.

> systemd will force me to do so?

No, systemd tries to load those modules but if you are into retro
computing you can still blacklist them using the usual modprobe
blacklisting, and systemd will honour that (i.e. by passing -b to
modprobe).

> Why it (a *program*) took upon itself to decide what modules should
> be running? There decisions are traditionally up to *humans*
> in Unix world.

Nah. udev loads modules automatically. In fact on almost all systems
there should be no need to ever load a module manually. And if the admin
wants to blacklist a module he can easily do so via the modprobe config,
how it should be done.

> > We don't replace syslogd, klogd, mount, fsck and dozen of other things.
> 
> What is /lib/systemd/systemd-fsck then?

A wrapper, which handles the exit code and reacts properly to it.

> /lib/systemd/systemd-logger?

It's service systemd uses to provide logging for processes it
spawns. i.e. in systemd you can simply configure in a service file that
stdout/stderr of a process should go to syslog, and this is needed for
that.

> (Also, most of them don't emit useful info on --help...)

They aren't user binaries. They are in /lib/systemd, not /usr/bin...

> > > Now I hear about plans to incorporate ConsoleKit into it
> > > (hearsay, so maybe it's not true).
> > 
> > Yes, systemd as a platform will include a tiny daemon which takes over
> > the role of CK.
> 
> That's what I was referring to by "taking over the world".

Well, we simplify things a lot that way, and unify the behaviour of
system and user services (i.e. they appear in the same cgroup hierarchy
and so on).

> Today I can remove CK from my Fedora install if I want to.

You'll be left with very little if you do that.

But why would you even want to remove that?

> If it goes into systemd, I will be unable to do so.
> Yet another bit of freedom taken away.

Yes, correct. I hate freedom. Muauauauahah!

> > I think systemd is much more optimized that what existed
> > previously. (what else is parallelization but optimization?) I bet with
> > you that a systemd system (modulo SELinux) can be built in a way that
> > uses much less resources and boot time than one built on Upstart.
> 
> I never used upstart. I used daemontools. I bet you can't beat *that*
> on resource front. Boot time is comparable.

daemontools does not support socket activation for parallelizing
execution of servers with its clients. So yes, we can beat *that*.

> > We simply spawn fewer (or even zero) shells and other interpretors, and
> > start a number of seldom-things only when needed and the rest in
> > parallel).
> 
> Optimizing towards not spawning shell at all is a strange optimization
> target. Reducing the need to spawn shells - yes, eliminating - no.

Well, zero might not be realistic anytime soon, but as mentioned, I want
to start fewer shells by default at boot.

> I don't say others must not use it, but I would like to be able
> to switch it off. (For one, it makes bloat more noticeable,
> so I can see what needs fixing.)

You can easily disable readahead:

systemctl disable systemd-readahead-replay.service systemd-readahead-collect.service

> > Nah, don't think so. We have fewer deps, and less dependencies than the
> > equivalent Upstart- and shell based boot.
> 
> Competing with Upstart is easy :)

Why do you say that? It's the benchmark so far. The best solution that
existed on Linux so far.

> > I find a system
> > whose PID after boot is in the 500 range much simpler and leaner than
> > one that is in the 5000 range.
> 
> That's what I was referring to by "taking over the world".
> You want to be "special". You want to have PID 1.

Hmm? systemd is an init system, so it is of course PID 1.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.