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

[Lennart Poettering]

On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk at redhat.com) wrote:

> Hi Lennart,
> 
> systemd is eating a lot more memory than any other init process
> I ever played with.
> 
> Granted, systemd does a bit more that "typical" init, but I think
> using *eleven plus megabytes* of malloced space is a bit much.

As pointed out elsewhere, this is mostly the SELinux policy, and
definitely something we can optimize in one way or another.

> I understand your desire to replace everything by systemd.

I have no such desire.

> I really do. syslogd, klogd, mount, fsck, and a dozen other things

We don't replace syslogd, klogd, mount, fsck and dozen of other things.

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

> Why does systemd link against libpam?
> systemd does logins now, not /bin/login or gdm or ...?
> libattr? Does it mean it requires filesystem which implements
> extended attributes? If not, why does it use libattr then?
> libaudit? What systemd has in common with audit?

Michal already answered these questions, so I am not going to repeat
this here.

> libwrap? systemd is a network application now too?

Yupp, Google for "socket activation systemd".

> libdbus?... this is a lost battle I guess...

Yupp, since Upstart used that already since ages.

> I propose to stop for a second and optimize systemd down
> instead of trying to add even more bells and whistles to it.
> Or else you'll soon end up linking against every /lib/lib*.so*

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. (How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).

> It is an *init replacement*, not the replacement for everything.

I like to see it as a modular platform to build an OS from. It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).

> Every new feature you add and library you link against
> works against that goal.

Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot. It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.

> To be honest, I doubt the wisdom of implementing service manager
> as an init process. There is no inherent reason why it has to be init -
> you can run it as *a child of init*, and keep init very simple.

No, that would complicate things for little reason. 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.

> Then, if service manager would crash, at least it doesn't
> take system down with it...

If systemd crashes it will freeze, but not take the system down.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.