Comment by J_McQuade
12 hours ago
Last year I decommed our last couple of servers that ran processes configured using runit. It was a sad day. I first learned to write runit services probably about 15 years ago and it was very cool and very understandable and I kind of just thought that's how services worked on linux.
Then I left Linux for about 5 years and, by the time I got back, Systemd had taken over. I heard a few bad things about it, but eventually learned to recognise that so many of those arguments were in such bad faith that I don't even know what the real ones are any more. Currently I run a couple of services on Pi Zeros streaming camera and temperature data from the vivarium of our bearded dragon, and it was so very easy to set them up using systemd. And I could use it to run emacsd on my main OpenSuse desktop. And a google-drive Fuse solution on my work laptop. "having something standard is good, actually", I guess.
The backlash against systemd was twofold. On one hand, when released and thrust upon distros via Gnome, it was quite rough around the edges, which caused both real problems and just understandable irritation. Fifteen years after, the kinks are ironed out, but it was sort of a long time. (Btrfs, released at about the same time, took even longer to stop being imprudent to use in production.)
On the other hand, systemd replaces Unix (sort of like Hurd, but differently). It grabs system init, logging, authentication, DNS, session management, cron, daemon monitoring, socket activation, running containers, etc. In an ideal Red Hat world, I suppose, a bare-metal box should contain a kernel, systemd, podman, IP tools, and maybe sshd and busybox. This is a very anti-Unix, mainframe-like approach, but for a big consulting firm, like Red Hat / IBM, it is very attractive.
All this lather about doing it the UNIX way, whilst neglecting to point out that the old tooling was far worse. "Do one thing well" implies it was done well to begin with.
DNS: Can you from memory recite how name lookups work on Linux? Ever had t otrack down problems with non-standard setups? `resolvectl` is not perfect, but it does let you control all of this stuff in one place, and with a nice, orderly view of what does what.
Init system: ever written the old sysV ones from scratch? Sure they're just shell script, but did you remember to make yours re-entrant? What about forking or master-slave processes? Hope you got your pid checking code just right...
Containers: Docker is quite robust nowadays but it's not like it follows the 'UNIX philosophy' either. And systemd/nspawn at least lets you do namespacing and cgroups reasonably well and in a straightforward way...
Mounts, etc.: let's not get into fstab and its idiosyncrasies.
Logging: let's hope you set up logrotate properly or you're in for a surprise.
And on it goes.
Systemd is not perfect. But what it replaces was god-awful and far worse.
No, systemd absolutely does not replace Unix.
Systemd-the-project and systemd-the-service-manager (“init”) are two different things. The former is a project with numerous components (e.g. resolved) that actually _are_ rather modular; they usually require systemd-the-service-manager, but you (or your distro) can generally pick and choose the components you want.
The service manager does indeed require some components to be gobbled up (udev comes to mind). But subsuming other subsystems shouldn’t be so anathema; the systemd people didn’t just think that “the one” thing of the Unix philosophy wasn’t being done well. Rather, the idea is that is was the wrong thing, i.e. classic Unix init was a tool operating at the wrong layer of abstraction. And in their eyes, a modern system needs a richer set of userspace primitives. So they made engineering decisions in pursuit of that goal.
Is following the "Unix way" a terminal value? I.e., is it desirable for itself, or is it just supposed to be a means to an end?
In discussions such as these, the Unix philosophy of "do one thing and do it well" is often being touted as a proxy for (and a necessary attribute of) "good design", as if all possible wisdom about the future of computing was available to the creators of UNIX in 1969.
The thing I don’t like about systemd is the inexplicable need to have multiple files for a service. Why can’t they all be declared in a single unit file?
What do you mean? They can be in a single service file.
All the examples I see is there’s a network unit file, a cron unit file, etc all for one application. It would be nice to colocate.
Then there is composition of multiple applications too.
With docker compose I have a single file for running all my services.
With systemd it has to be N number of files for each service too.
One of the main issues with systemd (as someone using it everywhere) is IMO that even experienced people can have a hard time understanding from which context a command is running.
E.g. if you "just" want to automate a script that you were running from a terminal as a user, there can be a ton of problems and it is hard to figure them out ahead of time.