Put Down the Pitchforks: systemd Is the Best Thing That Ever Happened to Your Server Room

Mention systemd at any Linux userspace meetup in this country and you'll get one of two reactions: a sigh, or a fifteen-minute rant about binary logs. The haters have had a good run. It's time somebody said the quiet part loud: systemd is good, actually, and most of the arguments against it don't survive contact with a real production environment.

The Case Against, Steel-Manned

Let's be fair to the other side, because the anti-systemd camp isn't wrong about everything.

The scope creep complaint is legitimate. PID 1 has no business knowing about DNS resolution, network time sync, or container management. The Unix philosophy says do one thing well, and systemd does approximately forty things with varying quality. Lennart Poettering's creation has swallowed more of the boot process than most people's entire init systems ever touched.

The binary journal format also earned its criticism. For years, if you wanted to grep your logs, you learned journalctl or you suffered. Text files are greppable by anything, forever, and no amount of journalctl -o json fully undoes the damage of that early decision.

And yes, the project's historical response to criticism — somewhere between dismissive and combative — didn't help. You don't win friends by telling the entire Debian community their concerns are invalid.

Now, The Case For

Here's what the ranters conveniently leave out: before systemd, init scripts were shell-script soup with race conditions baked in. Service startup order was a prayer. Dependency management was a comment in the header of a bash file that three people understood.

I watched a Fortune 500 retail company migrate a fleet of several thousand RHEL boxes from SysV init to systemd in 2018. Boot times dropped by more than half. Service failures that used to require a senior engineer with tribal knowledge now surfaced in systemctl status with an actual human-readable error. Their mean time to recovery on service incidents fell roughly 60 percent in the first year. That's not ideology. That's uptime.

The unit files alone justify the migration. Declarative, idempotent, dependency-aware — After=network-online.target replaced an entire genre of sleep 30 hacks that were holding up American commerce from coast to coast. Want automatic restart with backoff? Restart=on-failure. Want per-service resource limits, sandboxing, and seccomp filters without writing a single line of code? systemd gives you all of it, for free, on every box you'll ever touch.

The Scope Creep Is the Feature

Here's my contrarian take: the thing everyone complains about is the thing that makes it work.

The reason systemd can sandbox services, manage cgroups reliably, and know when a service is actually ready (not just "the process exists") is precisely because it's integrated. A modular init system where every component is swappable is also one where nobody knows whether the socket activation layer agrees with the session manager. Integration is how you get correctness. The Unix philosophy is beautiful in a textbook and brutal in an audit.

And the binary journal? In practice, journalctl is faster, richer, and more queryable than anything we had before. Structured metadata, persistent logs across reboots, and correlation across services — the old syslog setup gave you none of that. The haters were mad about format; the rest of us got better tooling.

The Verdict From the Field

Ask around any US enterprise shop running RHEL, Rocky, or Ubuntu LTS — which is to say, ask basically everyone — and you'll find systemd quietly running the place. Not because anyone loves it, but because it works, it's consistent, and it made a thousand implicit tribal-knowledge dependencies explicit.

Is PID 1 doing too much? Probably. Would I trade systemctl for a directory of hand-maintained init scripts and a support contract with the one guy who understands them? Not in this economy, and not on my watch.

systemd ate init. Frankly, init needed eating.