Nitro: A tiny but flexible init system and process supervisor

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.

You are repeating a bunch of "talking points" common among systemd-critics, but are not really backed up.

First of all, it wasn't "thrust upon" anyone, it was democratically selected multiple times in a ranked voting setup in case of Debian, and independently by Arch as well. It was simply because maintainers were fed up with the absolutely unmaintainable mess that predated systemd -- it seems random-ass bash scripts are not suitable for such a complex problem as booting up a system, and doing it properly is much better.

Logging sucked great time before, e.g. you didn't even get logs from before the Linux kernel is started - systemd moves it to a single place. And if you are for some reason irritated by binary logging, you can just freely pipe it to text logs.

Authentication is not done by systemd, are you thinking of pam modules? The network service is not systemd, just runs under the same group's name - KDE file browser is also different from their terminal. Also, it's not mandatory to use. Logind is not systemd itself, again. Scheduling services makes absolute sense for systemd's problem domain, so do monitoring and socket activation.

You need some kind of order to build stuff on, the Unix philosophy is more of a feel good convention than a real design guideline (and it doesn't apply in many cases)

> systemd replaces Unix

This is the over the top hyperbole the OP was talking about. Even if systemd did "replace Unix", I don't know why anybody should care.

As a long time Linux user it's clear that Systemd took over because it's better. The old way of doing things was a complicated mess that had evolved over decades, and was difficult to use and understand, with lots of weird interactions and no consistency.

Having a standard way to do admin tasks across all of the distros is valuable and makes Linux easier to use and more reliable.

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.

What do you mean? They can be in a single service file.

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.

If all you need is init (and not a process supervisor), docker comes with one called 'tini' built in. All you have to do is supply `--init` to the `docker run` command. Or use `init: true` in your docker-compose.yaml.

As far as a different process supervisor, I'm not sure. I've used supervisord and agree it's kind of awkward. I have heard of these but don't know much about them:

https://smarden.org/runit/

https://github.com/nicolas-van/multirun

https://github.com/just-containers/s6-overlay

Mostly just zombies and signal handlers.

And your software can do it, if it's written with the assumption that it will be pid1, but most non-init software isn't. And rather than write your software to do so, it's easier to just reach for something like tini that does it already with very little overhead.

I'd recommend reading the tini readme[0] and its linked discussion for full detail.

[0]: https://github.com/krallin/tini

The main other problem is that the kernel doesn't register default signal handlers for signals like SIGTERM if the process is PID 1. So if your process doesn't register its own signal handlers, it's hard to kill (you have to use SIGKILL). I'm sure anyone who has used Docker a lot has run into containers that seem to just ignore signals -- this is the usual reason why.

> also, why can't the real pid1 do it? it sees all the processes after all.

How would the real PID 1 know if it _should_ reap the zombie? It's normal to have some zombie processes -- they're just processes whose exit statuses haven't been reaped yet. If you force-reaped a zombie you could break a program that just hasn't yet gotten around to checking the status of a subprocess it spawned.

I've always advocated against containers as a means of deploying software to robots simply because to my mind it doesn't make sense— robots are full of bare-metal concerns, whether it's udev rules, device drivers, network config, special kernel or bootloader setup, never mind managing the container runtime itself including startup, updating, credentials, and all the rest of it. It's always felt to me like by the time you put in place mechanisms to handle all that crap outside the container, you might as well just be building a custom bare metal image and shipping that— have A/B partitions so you copy an update from the network to the other partition, use grub chainloading, wipe hands on pants.

The concern regarding license-adherence is orthogonal to all that but certainly valid. I think with the ROS ecosystem in particular there is a lot of "lol everything is BSD/Apache2 so we don't even have to think about it", without understanding that these licenses still have an attribution requirement.

Except when you need a different version of postgresql than the one packaged by Ubuntu, you have to use ppas or something even more horrific: snaps. Otherwise you just put your stuff in a container, problem solved. I'm not for containerizing everything, it just adds useless complexity. But it's a useful tool.

It's only really fixed in podman, with the special `--systemd=always` flag. Docker afaik still requires manually disabling certain services that will conflict with the host and then running the whole thing as privileged— basically, a mess.

Not my favoured approach, but for early stage systems where proper off-board observability/alerting is not yet in place, tmux can function as a kind of ssh-accessible dashboard displaying the stdout of key running processes, and also allowing some measure of inline recovery— like if a process has crashed, you can up-arrow and relaunch it in the same environment it crashed out of.

Obviously not an approach that scales, but I think it can also work decently well as a dev environment, where you want to run "stock" for most of the components in the system, and just be syncing in an updated workspace and restarting the one bit being actively developed on. Being able to do this without having to reason about a whole tree of interlinked startup units or whatever does lower the barrier to entry somewhat.

dinit is another one with service dependency support

So it's basically like tini (keep a single executable running), but in Rust?

It is lightweight, very easy to understand and reason about (much more than systemd - and it’s not just an issue of familiarity - it has much fewer moving parts than systemd’s service management part).

It’s rock solid. It goes to great length to never lose process output, not even a single char, across service restarts. (it might be possible to achieve same on systemd - but it isn’t trivial)

And it’s been that way for me for two decades now - Ubuntu moved from system v to upstart to systemd; my systems still use the same daemontools setup they used 15 years ago, they do it on FreeBSD and Linux. And they just work, no surprises.

Hmm, is that desirable? If someone's going around sending SIGTERM to random processes they might also send SIGKILL, and there's no way Nitro can propagate SIGKILL to processes it starts.

It does if you use SIGHUP.

Dinit, runit, tini -- all avoid the name clash :)