systemd: please stop trying to take over the world :)
mzerqung at 0pointer.de
Mon Jun 13 08:15:34 UTC 2011
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
> 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
> 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 Poettering - Red Hat, Inc.
More information about the devel