[systemd-devel] Please proof-read: systemd’s dependencies and installation footprint

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jun 08, 2013 at 05:39:48PM +0200, Michael Stapelberg wrote:
> Hi Zbigniew,
> 
> Thanks for your answer.
> 
> Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> writes:
> > "The binaries systemctl (299 KiB), journalctl (187 KiB) and loginctl
> > (91 KiB) are the main binary to use for respective part of system"
> > → it's a bit unclear what "to use for" means in this context.
> Clarified.
> 
> > "pixel-perfect" → not true for a long time, since now we do coloring
> > and such, maybe "character-perfect" would be more adequate
> Fixed.
> 
> > "journal log" → journal
> Fixed.
> 
> > "there is no cyclic dependency" → actually there's a *compile time*
> > cyclic dependency, so it might be good to add an adjective that makes
> > it clear that you mean startup order dependency
> Fixed.
> 
> > OK, you start talking about systemd, and than about libudev, and
> > serial ports, and it all becomes really muddy. Maybe it would be
> > better to first get systemd-udevd out of the way, especially that
> > udevd is used by everybody, so it is always loaded anyway, so the cost
> > of libudev.so.1 in PID 1 is nearly nil.
> udevd does not use libudev.so AFAICT. It does not show up in ldd
> /lib/systemd/systemd-udevd
Right. But other stuff in /lib/udev/ uses it, e.g. accelerometer,
cdrom_id, udisks stuff.

> > "To be honest, I don’t quite understand why this code is not inlined
> > into systemd. " → why should it be? It is rather worth explaining why
> > there's so much stuff in systemd. There's a reason why other code *is*
> > inlined into systemd, when it *could* be provided as a shared library.
> > The stuff that is part of static libsystemd-shared during compilation
> > is inlined and not shared between all the systemd components as a
> > shared library because it would have to be installed in /usr/lib and
> > other people could link against it. But we don't want to provide any
> > promises regarding the stability of the internal library API, so we
> > take the (small) cost of static linking over the hassles that come
> > with having a private library in a public place. There's no such
> > consideration for libsystemd-daemon, because it has a public API that
> > is stable.
> Fixed.
> 
> > "helper utilities" → why are there crosses and check marks, what's the
> > difference?
> ✘ means no, ✔ means yes. In the particular case it means whether the
> specific binary depends on e.g. udev or not. I thought that’s obvious,
> but I’ve clarified it.
>
> > "systemd-shutdown PID 1 will be replaced with this binary" → when?
> > Maybe mention that systemd-shutdown is statically linked (I know it
> > can be inferred from the text, but being explicit might be better).
> Clarified.
> 
> > "Debugging, interactive tools, shell helpers ... systemd-readahead":
> > I would say that systemd-readahead doesn't really fall into any
> > of those categories.
> Indeed. There’s no better category, though, so I’ll just leave it as-is.
> 
> > "systemd-nspawn ... for debugging" → not really, since it has gained
> > the ability to socket activate containers, people use it also for
> > production (e.g. compilation chroots, web server environenments, etc).
> Added.
> 
> > "systemd-detect-virt ... Depending on your environment, you might not
> > want to start certain services — for example udev does not make sense
> > in an lxc container" → this is a bit misleading, because services
> > would be started or not using systemd's built-in ConditionVirtualization,
> > and this binary is for other uses.
> For what uses specifically?
Don't know off the top of my head, but udevd was just a bad example.
systemd-detect-virt is for installation scripts and other stuff which
is not tied to systemd directly.

> > "so that the only thing journald does is passing information to syslog"
> > → it also stores stuff temporarily in tmpfs.
> Clarified.
> 
> > What I'm missing from all this, is the answer to the question set
> > forth in the title: what is the *total* footprint of running a normal
> > systemd installation (I'd be happy to see some good statistics and
> > analysis!). PID 1 is probably the heaviest, but journald also
> > contributes, and it would be nice to see the whole picture.
> I’m working on additional measurements which outline the memory
> requirements for an entire sysvinit boot and systemd boot. I’ll update
> you once that is done.
Great, I hope that this will help in the discussion.

Zbyszek