Hacker News Reader

I think what the parent poster meant is that despite being modularized into several components, systemd has interdependencies between them, its individual subsystems not being able to be seamlessly swapped out. Indeed, many components (nspawn included) depend on systemd-as-PID1. As such it is monolithic.

Uh, that's what I would have expected from an init system. And nspawn is for testing and debugging, not for production use.

...and I hardly consider sysvinit to be a great example of such a thing - a bunch of cobbled together shell scripts serialised into a particular order isn't particularly clean or elegant.

You're confusing sysvinit with sysv-rc

No, I was unclear and referring to the source package, which was a bit silly of me. But you knew what I meant.

You do realize that there are only a few binaries?

Have you actually compiled systemd? The binaries probably exceed a hundred at this point. The count given for 204 was 69.

What's your point? Let's look at utility and core binaries:

Utility binaries, don't rely directly on PID 1:

/bin/journalctl /bin/loginctl /bin/machinectl /bin/systemctl /bin/systemd-escape /bin/systemd-inhibit /bin/systemd-machine-id-setup /bin/systemd-notify /bin/systemd-tmpfiles /bin/systemd-tty-ask-password-agent /bin/systemd-ask-password /lib/systemd/systemd-ac-power /lib/systemd/systemd-activate /lib/systemd/systemd-backlight /lib/systemd/systemd-binfmt /lib/systemd/systemd-bootchart /lib/systemd/systemd-cgroups-agent /lib/systemd/systemd-cryptsetup /lib/systemd/systemd-fsck /lib/systemd/systemd-initctl /lib/systemd/systemd-modules-load /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-quotacheck /lib/systemd/systemd-random-seed /lib/systemd/systemd-readahead /lib/systemd/systemd-remount-fs /lib/systemd/systemd-reply-password /lib/systemd/systemd-rfkill /lib/systemd/systemd-shutdown /lib/systemd/systemd-sleep /lib/systemd/systemd-sysctl /lib/systemd/systemd-update-utmp /usr/bin/busctl /usr/bin/hostnamectl /usr/bin/localectl /usr/bin/systemd-analyze /usr/bin/systemd-cat /usr/bin/systemd-cgls /usr/bin/systemd-cgtop /usr/bin/systemd-delta /usr/bin/systemd-detect-virt /usr/bin/systemd-nspawn /usr/bin/systemd-path /usr/bin/systemd-run /usr/bin/systemd-stdio-bridge /usr/bin/timedatectl

Relies on PID 1:

/bin/systemd

Important binaries that rely on systemd, but that don't run on PID 1:

/lib/systemd/systemd-bus-proxyd /lib/systemd/systemd-hostnamed /lib/systemd/systemd-journald /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-logind-launch /lib/systemd/systemd-machined /lib/systemd/systemd-networkd /lib/systemd/systemd-networkd-wait-online /lib/systemd/systemd-resolved /lib/systemd/systemd-shutdownd /lib/systemd/systemd-socket-proxyd /lib/systemd/systemd-timedated /lib/systemd/systemd-timesyncd /lib/systemd/systemd-user-sessions

With two caveats: Forwarding to other sources has a priority loss and doesn't have the same reliability/ordering/completeness guarantees (even if the claim is they "try hard": https://wiki.freedesktop.org/www/Software/systemd/syslog/), journald hijacks /dev/log and expects all syslogd implementations to conform to its own standard.

What? Where are you getting this from? Prove it. You misquote them though, as they say:

"Note that journald tries hard to forward to your BSD syslog daemon as much as it can. That means you will get more than you traditionally got on /dev/log, such as stuff all daemons log on STDOUT/STDERR and the messages that are logged natively to systemd. Also, we will send stuff like the original SCM_CREDENTIALS along if possible."

logind handles logins

Far more than that. It handles user sessions, seats, suspend/hibernate, some device enumeration, gettys and as of recent, system shutdown. It's basically an extension from system init to session init.

You are correct, I was not very clear. Not sure I see the problem here though.

Do you even understand what socket activation is? It's a marketing buzzword for an old and simple concept, and the systemd definition in particular conflates multiple use cases. See this commentary by Laurent Bercot: https://forums.gentoo.org/viewtopic-t-994548-postdays-0-post....

Yup, I do. Interesting comments from Laurent Bercot, unlike you he sees that the idea has merit.

But a few things:

1. He's claiming that Pottering claims to have invented the concept of a superserver, where it was invented in inetd. Small problem: Pottering openly states this in 2011, here: http://0pointer.de/blog/projects/socket-activation.html also he seems to be claiming that Pottering says he invented pre-opened file descriptors? Guy is being a bit of an idiot as Pottering never said this.

2. He's complaining about a registry of predefined sockets in configure files. Seriously? That's his big concern? You deploy a daemon that can do socket-activation and you can't either create a configure file or include one with the package? Wake me up with a real argument, please.

3. He misses the point that socket activation means that you don't have to predefine the service order, by using sockets the service will block till the other service starts. I guess my only concern (that I've just though of) is how systemd handles deadlock conditions, but that isn't a stated concern about reliability by Bercot. Bercot's main concerns are: 1. what happens if a dependent service hangs, and 2. What happens if it's in the middle of a transaction.

I guess my response is: 1. Yes, it will block forever - but if your service was reliant on a serialised startup then I'm not sure what difference this makes: what happens if an earlier service hangs and dependent services can't run until that service has started? That used to happen to me on RedHat 5 when I accidentally forgot to turn off my misconfigured NFS server :-) 2. If you are in the middle of a transaction then again, I can't see how it's any worse than the scenario I just presented.

Those features could be part of a process manager or a process supervisor, not init(8) itself. init(8)'s duties are reaping orphaned processes and handling high-level global system state at best (like SAK, shutdown, halt, etc.)

init doesn't reap orphaned processes, it reaps zombie processes. But actually, there are pretty decent technical reasons for it to handle these duties - like it handles misbehaving daemons that orphan themselves.

It should not entangle the state of the system with the state of the OS processes, which systemd does quite egregiously. For example, even Apple had the engineering sense to separate their launchd plist configuration parser from the launchd PID1 itself.

What... What?

"After the system is booted and the kernel is running, launchd is run to finish the system initialization. As part of that initialization, it goes through the following steps: It loads the parameters for each launch-on-demand system-level daemon from the property list files found in /System/Library/LaunchDaemons/ and /Library/LaunchDaemons/." https://developer.apple.com/library/mac/documentation/MacOSX...

But, uh - ever heard of systemctl?

View on HN

0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0] 0x0000000000000001 (NEEDED) Shared library: [libudev.so.1] 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] 0x0000000000000001 (NEEDED) Shared library: [libaudit.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcap.so.2] 0x0000000000000001 (NEEDED) Shared library: [libkmod.so.2] 0x0000000000000001 (NEEDED) Shared library: [libdbus-1.so.3] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]