◆ THE UNIX WAY ◆
Episode 04: Service Management
You want your application to start at boot, restart on failure, and stop cleanly. One job. Terribly straightforward, one would think.
■ FreeBSD
On FreeBSD, a service is a shell script. Ten lines of /bin/sh, a few comment lines declaring dependencies (REQUIRE, BEFORE, AFTER), and a shared function library that handles the rest. Enable it with one command, start it with another, done.
Debugging? Run the script with sh -x. Read it with cat. Trace the entire execution path with tools that existed before you were born.
178 shell scripts in /etc/rc.d/. One shared library. One config file (rc.conf). One small C utility to sort the boot order. That is the entire init system.
■ Linux (systemd)
systemd also starts services. Rather well, in fact. The service definition is clean, declarative, roughly ten lines. No complaints there.
The difficulty begins when you ask what else is running.
systemd ships approximately 150 compiled binaries. In 2013, it shipped 69. It manages services, logging (binary format), DNS, networking, containers, timers, mounts, device management, home directories, boot loading, credential management, and as of 2024: privilege escalation. It replaced sudo. With itself.
690,000 lines of C. 2 million in the repository. 6,363 files.
It absorbed 15 separate Unix tools: syslog, cron, inetd, udev, NTP, DHCP, ConsoleKit, and more. Each was independent. Each was replaceable. Now they share one project, one release cycle, one PID 1.
Then there are the logs. FreeBSD writes plain text to /var/log/messages. grep, awk, tail, cat. After a crash, boot from USB, read the file. Done.
systemd writes binary logs via journald. After a crash, you need a working journalctl to read them. If the journal is corrupted (and it does corrupt), you need nothing, because you have nothing.
Linus Torvalds: "I think some of the design details are insane. I dislike the binary logs, for example." When the creator of Linux calls your logging insane, one might pause to reflect.
■ THE QUIET PART
PID 1 is special. If it crashes, the kernel panics. The entire machine goes down. On FreeBSD, PID 1 is init: it forks, it reaps zombies, it does nothing else. Rich Felker demonstrated this requires 15 lines of C.
On systemd, PID 1 processes D-Bus messages, handles notifications, and manages an internal state machine. In 2016, any unprivileged local user could hang PID 1 with a single empty message. Services stopped starting. SSH hung. Clean reboot became impossible.
The question is not whether systemd is capable. It is. Impressively so.
The question is whether your PID 1 should also be your DNS resolver, your log daemon, your container manager, and your sudo replacement.
On FreeBSD, these are separate tools. If one breaks, the others continue.
That used to be called the Unix philosophy.
#TheUnixWay #FreeBSD #Linux #systemd #DevOps