zlacker

>>todsac+(OP)
I would like a comparison with runit, which is a very minimal but almost full-fledged init system. I see many similarities: control directories, no declarative dependencies, a similar set of scripts, the same approach to logging. The page mentions runit in passing, and even suggests using the chpst utility from it.

One contrasting feature is parametrized services: several similar processes (like agetty) can be controlled by one service directory; I find it neat.

Another difference is the ability to initiate reboot or shutdown as an action of the same binary (nitroctl).

Also, it's a single binary; runit has several.

>>nine_k+0k
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.

>>J_McQu+nX
I made a process supervisor, probably less simple than nitro but much more simple (and focused) than systemd.

Aside from the overreach, I think there are some legitimate issues with systemd:

- It's really hard to make services reliable. There are all sorts of events in systemd which will cause something to turn off and then just stay off.

- It doesn't really help that the things you tell it to do (start/stop this service) use the same memory bits as when some dependency turns something on.

- All the commands have custom, nonstandard outputs, mostly for human consumption. This makes it really hard to interface with (reliably) if you need to write tooling around systemd. Ini files are not standardized, especially systemd's.

- The two way (requires, requiredby) dependencies make the control graph really hard to get a big picture of

FWIW here's mine, where I wrote a bit more about the issues: https://github.com/andrewbaxter/puteron/