On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk(a)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.