5 ms·

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

by nine_k 1y ago

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.

imiric 1y ago
I've gotten used to runit via Void Linux, and while it does the job of an init system, its UI and documentation leave something to be desired. The way logging is configured in particular was an exercise in frustration the last time I tried to set it up for a service. I wouldn't mind trying something else that is as simple, but has sane defaults, better documentation, and a more intuitive UI.
- nine_k 1y ago
  Logging in runit seems simple (I don't remember running into problems), but indeed, the documentation leaves much to be desired. Could be a good thing to contribute to Void Handbook.
- cbzbc 1y ago
  runit doesn't always take care of services it manages in the same way as a proper init . From the man page: "If runsvdir receives a TERM signal, it exits with 0 immediately"
  - Arch-TK 1y ago
    This is by design. runsvdir receiving TERM should only happen when stage 2 is triggered to end. Once that happens, the individual runsv processes are still supervising their individual tasks and can be requested to stop through their respective control sockets. It's how standard stage 3 is implemented.
- kccqzy 1y ago
  I like using systemd but it also doesn't have great documentation either. I often find myself unable to grok things by only reading the official documentation and I have to resort to reading forum posts, other people's blogposts or Stack Overflow. To me documentation isn't good enough until it doesn't need any third party material.
- JdeBP 1y ago
  These aren't runit doco, but they should help with the concepts. * https://jdebp.uk/FGA/daemontools-family.html#Logging https://jdebp.uk/FGA/daemontools-family.html#Logging * https://jdebp.uk/Softwares/nosh/guide/logging.html https://jdebp.uk/Softwares/nosh/guide/logging.html
smartmic 1y ago
Leah Neukirchen is active member of the Void Linux community, I expect a lot of cross-pollination here. It would be really great if she could write up something how to use it for Void.
J_McQuade 1y 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.
- nine_k 1y ago
  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.
  - mickeyp 1y ago
    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.
ethersteeds 1y ago
> no declarative dependencies, Is that a selling point? Could you explain why? I've heard plenty of reasons why people find systemd distasteful as an init, but I've not heard much criticism of a declarative design.
- petre 1y ago
  > Is that a selling point? Could you explain why? Because it's stupid easy? I just have to execute shell one liners and set environment variables, no need to read lenghty docs and do stuff the systemd way. We use runit to supervise our services. It's 100% reliable as opposed to systemd which sometimes fails in mysterious ways.
fbarthez 1y ago
There's an appropriately minimal comparison with runit in her slides (PDF) from a talk she gave in 2024: https://leahneukirchen.org/talks/#nitroyetanotherinitsy https://leahneukirchen.org/talks/#nitroyetanotherinitsy
- cout 1y ago
  What I got from looking at that comparison is that runit starts a separate supervisor process for each process started. I like the cleaner process tree of nitro, but I wonder what the tradeoffs are for each.

by nine_k 1y ago

imiric 1y ago

I've gotten used to runit via Void Linux, and while it does the job of an init system, its UI and documentation leave something to be desired. The way logging is configured in particular was an exercise in frustration the last time I tried to set it up for a service. I wouldn't mind trying something else that is as simple, but has sane defaults, better documentation, and a more intuitive UI.

nine_k 1y ago
Logging in runit seems simple (I don't remember running into problems), but indeed, the documentation leaves much to be desired. Could be a good thing to contribute to Void Handbook.
cbzbc 1y ago
runit doesn't always take care of services it manages in the same way as a proper init . From the man page: "If runsvdir receives a TERM signal, it exits with 0 immediately"
- Arch-TK 1y ago
  This is by design. runsvdir receiving TERM should only happen when stage 2 is triggered to end. Once that happens, the individual runsv processes are still supervising their individual tasks and can be requested to stop through their respective control sockets. It's how standard stage 3 is implemented.
kccqzy 1y ago
I like using systemd but it also doesn't have great documentation either. I often find myself unable to grok things by only reading the official documentation and I have to resort to reading forum posts, other people's blogposts or Stack Overflow. To me documentation isn't good enough until it doesn't need any third party material.
JdeBP 1y ago
These aren't runit doco, but they should help with the concepts. * https://jdebp.uk/FGA/daemontools-family.html#Logging https://jdebp.uk/FGA/daemontools-family.html#Logging * https://jdebp.uk/Softwares/nosh/guide/logging.html https://jdebp.uk/Softwares/nosh/guide/logging.html

smartmic 1y ago

Leah Neukirchen is active member of the Void Linux community, I expect a lot of cross-pollination here. It would be really great if she could write up something how to use it for Void.

J_McQuade 1y 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.

nine_k 1y ago
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.
- mickeyp 1y ago
  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.

ethersteeds 1y ago

> no declarative dependencies, Is that a selling point? Could you explain why? I've heard plenty of reasons why people find systemd distasteful as an init, but I've not heard much criticism of a declarative design.

petre 1y ago
> Is that a selling point? Could you explain why? Because it's stupid easy? I just have to execute shell one liners and set environment variables, no need to read lenghty docs and do stuff the systemd way. We use runit to supervise our services. It's 100% reliable as opposed to systemd which sometimes fails in mysterious ways.

fbarthez 1y ago

There's an appropriately minimal comparison with runit in her slides (PDF) from a talk she gave in 2024: https://leahneukirchen.org/talks/#nitroyetanotherinitsy https://leahneukirchen.org/talks/#nitroyetanotherinitsy

cout 1y ago
What I got from looking at that comparison is that runit starts a separate supervisor process for each process started. I like the cleaner process tree of nitro, but I wonder what the tradeoffs are for each.