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

[Michael Stapelberg]

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

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

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

-- 
Best regards,
Michael