cross-posted from: https://programming.dev/post/36342010
Nitro is a tiny process supervisor that also can be used as pid 1 on Linux.
There are four main applications it is designed for:
- As init for a Linux machine for embedded, desktop or server purposes
- As init for a Linux initramfs
- As init for a Linux container (Docker/Podman/LXC/Kubernetes)
- As unprivileged supervision daemon on POSIX systems
Nitro is configured by a directory of scripts, defaulting to /etc/nitro (or the first command line argument).
Every Linux user actually hates SystemD, but we pretend to like it to show superiority over other Operating Systems.
I wrote and maintained a lot of sysvinit scripts and I fucking hated them. I wrote Upstart scripts and I fucking hated them. I wrote OpenRC scripts and I fucking hated them. Any init system that relies on one of the worst languages in common use nowadays can fuck right off. Systemd units are well documented, consistent, and reliable.
From my 30 seconds of looking, I actually like nitro a bit more than OpenRC or Upstart. It does seem like it’d struggle with daemons the way sysvinit scripts used to. Like, you have to write a process supervisor to track when your daemonized process dies so that it can then die and tell nitro (which is, ofc, a process supervisor), and it looks like the logging might be trickier in that case too. I fucking hate services that background themselves, but they do exist and systemd does a great job at handling those. It also doesn’t do any form of dependency management AFAICT, which is a more serious flaw.
Nitro seems like a good option for some use cases (although I cannot conceive why you’d want to run a service manager in a container when docker and k8s have robust service management built into them), but it’s never touching the disk on any of the tens of thousands of boxes I help administrate. systemd is just too good.
This does not seem very different from runit, so you probably do things similarly. Dependencies are done by checking if the dependency is running inside the script. Presumably you deal with daemons by
execing the daemon, so that the daemon becomes the script, not a separate process.No, but the weirdos who insist on spelling it “SystemD” always seem to hate systemd.
systemd is pretty great. I tend to start long-running processes as user services, and I’ve even taken to starting some apps that give an old laptop trouble with
systemd-runand a slice with some memory restrictions. Easy peasy, works great, all declarative, no wibbly-wobbly shell scripts involved.More like system deeznuts!
(Sorry, I just wanted to say that. 😅)
“SystemD”
@Pro @syklemil I don’t get it either. I tried asking around in the past and it seems to come from a hate for Lennart, which gets hated for creating systemd… Something like that. It didn’t really make sense. I’m interested in newer alternatives of course but I personally use systemd all the time since 2016 at least and I don’t see any problems with it
Having given a shot to OpenRC on Alpine systems, I would say that I prefer systemd for creating and managing services.
I like its unified logging, which extends even beyond the host, integrating the logs of nspawn containers. I like its tmpfiles, which allows configuring temporary files, without writing scripts that create/cleanup them.
I have to admit, however, that I don’t like all of its subsystems. For example, I don’t want networkd and resolved anywhere near my configuration.
I love networkd only issue is lack of documentation. Still can’t believe so many systems are using an unmaintained DHCP client. One of the reasons I even bothered is I didn’t like using the unmaintained one.
I like it. Good logging easier to write and trouble shoot start up scripts.