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

Mon Jun 13 16:01:22 UTC 2011

On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
> 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.

You assume that everyone uses IPv6. This is not true.

> 
> >                 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,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.

Why do you set up stuff no one asked you to?

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

Point me at one program which uses machine id. I never saw one.
And anyway, why do you set up stuff no one asked you to?

> > "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.

Plymouth is not a part of Unix. Init process has no business knowing
about distro specific stuff like that.

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

Where did I propose turning everything into a separate binary?

> 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?

Because it's a perfect example of a thing init process has no business
doing. Ever. The lightness of the syscall is irrelevant. For example,
you also do modprobing of various things, which is far from being
"just one syscall", so this argument is moot.

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

Init process should not have intrinsic knowledge about splash screens!
This is basic idea of modularity. This is how Unix always worked.
Things should not be *too* interconnected. Things should be modular.

In your presentation, you have "Integration" as slide 17 and
"Modularization" as slide 18. Do you realize that these are the opposite
things? "More integration" means "less modularization". You can't have
both.

> systemd is not running Plymouth stuff in the same process, is it merely
> communicating with it.

Thanks that at least for now you don't have plans to incorporate
Plymouth.

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

udev loads modules according to config file, not by hard-coding stuff in
C code. IOW: udev does not load modules which *udev developer*
wants, it loads modules which *admin* wants. (Of course,
admin might choose to use standard config, but he does this
on his own volition).

> In fact on almost all systems
> there should be no need to ever load a module manually.

Maybe. It's not up to a piece of software to decide.
In Unix, admins should have power to decide, not programs.
Programs provide the means, they don't dictate policies.

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

Try "rm /usr/sbin/console-kit-daemon". Works like a charm.

> But why would you even want to remove that?

If I would be willing to work in an OS with attitudes like this,
I'd be hacking in Windows. I don't.

> > > 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*.

I said "you can't beat *that* on resource front". On resource front.
Can you beat it on resource front?

Indeed, daemontools don't provide socket activation. Please note that I
don't argue against socket activation.

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

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

-- 
vda