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

[Lennart Poettering]

On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk at redhat.com) wrote:

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

No I am not. You can still blacklist the ipv6 module if you want to via
the normal modprobe blacklisting mechanisms. (As mentioned, systemd
passes -b to the modprobe command line to ensure that). I explicitly
said that in a previous mail.

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

(none) is what the bash makes from empty hostname, which is the
default. We just fill in one.

Just because systemd sets up a hostname at boot it doesnt mean it
couldn't be changed dynamically later on. In fact if you are into
dynamic hostnames you should send me a big cake for my birthday as thank
you, because I give you stuff like this for F16:

https://fedoraproject.org/wiki/Features/nssmyhostname

http://www.freedesktop.org/wiki/Software/systemd/hostnamed

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

Yeah, I explained that already.

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

/etc/machine-id is a generalization of the D-Bus machine id, which is
used by quite a number of programs directly and indirectly. With systemd
we try to make this available globally and independently of D-Bus and
add new semantics for stateless systems.

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

Well, since you appear to have invented Unix I think we simply have to
disagree here. 

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

Well, I say calling sethostname() is a syscall we should simply do in
PID 1 and then forget about, but you want this in a separate process
(hence 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.

Well, I guess we simply have to disagree. My interest is a tighly
integrated, small, minimal, lightweight system. Yours seem to be a big,
archaic, chaotic, redundant, resource intensive system. But that's fine.

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

systemd knows nothing about splash screens. All it does is send status
updates to Plymouth.

> This is basic idea of modularity. This is how Unix always worked.
> Things should not be *too* interconnected. Things should be modular.

And they are. Plymouth and systemd are two separate modules, which
however communicate with each other (actually, strictly one way).

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

Oh, of course you have. You must have that. The kernel for example is
one module of the OS, your syslog another, and and your cron
another. And don't tell me they wouldn't communicate with each
other. They do; *of course* they do. Modularization without
communication is uselessness.

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

Dude, "for now", thanks for that. I mean, thanks for implying I had evil
plans which I just wouldn't show right now. I mean seriously dude,
there's really no point in doubting everything I say. Because if you do
I see little point in even bothering with responding to you. Because if
you want to believe what you believe regardless what I say I see no
point in saying it.

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

That is simply not true. Of course the autoloading rules are all
compiled into the kmods.

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

Dude, systemd requires the functionality of the three modules it loads
explicitly. It needs it at a time where udev is not running, hence
autoloading doesn't work. There is *no* *other* *option* to work
properly than to explicitly load those modules.

And really, systemd honours the modprobe blacklist, and does so
explicitly (i.e. the modprobe -b switch), so systemd enforces very
little. it just makes sure it works properly in the default case on
distros which do not compile the modules in question into the kernel.

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

Yeah, and equally well or badly "rm /lib/systemd/systemd-logind" will
work.

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

You apparently have very little idea how Windows works.

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

I mean, this is like comparing apples and oranges. systemd gives you an
OS building box, daemontools nothing but a service supervisor. If you
use daemontools you also need an init system, and boot scripts, and
everything else. So yeah, if you compare systemd and
daemontools+sysvinit+initscripts then, hell yeah, I can beat that.

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

Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized
processes. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.