Systemd: Why is it So Controversial? A Balanced Look at the Pros and Cons.

What I Saw in the IRC Channel Last Night

Picture this. I’m lurking in #linuxadmin at 2 AM. The topic comes up again. “systemd is eating my morning takes forever.” Within 30 seconds, half the room is screaming “monolithic garbage!” while the other half chants “just learn the tools” and links the same wiki page.

Same fight, every month.

I used to join in. Took me two years to realise we’re all talking past each other.

Why a startup silently joined the dark side

2019. My tiny startup ran a hobby VPS to host webhooks. Classic move: Ubuntu minimal, SysV, one cron job. Life was good.

Then the reboot loops started. Service A needed eth0 up, which wanted Resolver B, which expected a volume to mount. The dependency graph looked like tangled Christmas lights.

Deadline was Monday. I installed systemd just to get parallel boot. Five minutes later the box popped up. The team cheered. I died a little inside.

What makes smart people furious

• “It does too much.” One process owns your logs, your sockets, your users… and you’re two key-strokes away from nuking the kernel. Feels wrong.
• You can’t read it. Used to be a bash script. Now it’s an INI file talking to D-Bus talking to PID 1.
• Upgrade gut-punch. Yesterday `tail -f /var/log/myapp` worked. Today… binary blobs.

Debian 2014. The vote came in 4:3. I watched devs literally pack their bags and start Devuan. No joke—flannel shirts, tower PCs in carry-on, Discord channels exploding. That energy never settled.

The other side (the side I live with)

The room-temperature take: parallel startup actually saved my sleep.

Consistent commands:

systemctl restart myapp   # works on laptop, cloud, Pi
systemctl disable docker  # still disabled after dist-upgrade

Plus the bundled goodies—cgroups, socket activation, watchdogs—used to require six separate daemons and duct tape.

Still bug me? Absolutely. But production doesn’t care about your feelings.

How I stay (relatively) calm

• Minimal install only. On my laptop I drop everything except systemd-resolved and –user slice. Keeps the attack surface sane.
• Debug mode still works. Add systemd.debug-shell=1 to grub line → instant root shell at emergency targets. Old-school rescue.
• Logs aren’t locked away. I pipe journal to plain text as a crutch:
  ForwardToSyslog=yes in /etc/systemd/journald.conf → write to plain files, tail, grep, back to sleep.
• Keep other tools alive. My lab still runs Gentoo/OpenRC on one SSD. Reboots faster, teaches the kids init scripts.

The checklist I hand to new teammates

1. Want super-tiny VM? Go Alpine / OpenRC.
2. Need container distro that matches prod? Learn systemctl. Two extra commands, not a religion.
3. Hate monoliths? Ask the CTO if you can ship a Devuan iso for your embedded board. Watch their wallet recoil.

That’s it. Stop yelling. Read the room.

An honest sidebar nobody scrolls to

I still keep the SysVinit Clonezilla USB in a drawer. Nostalgia therapy. Yesterday I booted an ancient laptop, watched init scripts scroll by like green rain. Warm bath of Unix zen.

Five minutes later the fans purred, the kernel loaded, the screen stayed black because… udev rules mismatch. Spent 40 minutes googling why the agp driv—nevermind. Lesson learned. Progress has edges.

So here we are. systemd is the default init the same way smartphones killed flip phones. You can romanticise the flip phone, or just pocket the smartphone and get on with running servers. Both feelings fit in one brain.

Real talk: the debate here isn’t about binaries. It’s about change you didn’t ask for. Been there. Still there. The hack is accepting the parts that pay your mortgage while carving space for the parts that keep your soul intact.

Time to close IRC window. Real servers are humming in the other room, all systemd. They boot quicker. Now I can sleep longer.

Postscript for the curious: last month’s release of systemd 256 added an `–help` flag that finally shows the man pages inline. One small olive branch. I’ll take it.