Nitro: A tiny but flexible init system and process supervisor

This Hacker News discussion revolves around a new init project called "Nitro" and compares it to existing init systems, with a significant portion of the conversation dedicated to the use of init systems within containers and the broader philosophy of system design.

Comparison to Existing Init Systems

The primary theme is how Nitro stacks up against established init systems, particularly runit and s6. Users are looking for differentiating features and advantages.

• "love to see new init projects. how does it stack up against runit (the last one i really familiarized myself with on void linux)?" asked GuinansEyebrows.
• kragen noted, "She credits runit and daemontools as inspiration, and it looks extremely similar. I hope that at some point she writes a comparison explaining what Nitro does differently from runit and why."
• cbzbc raised a specific point about runit: "runit doesn't propagate SIGTERM to services it starts."
• kragen questioned the utility of this, "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."
• atahanacar offered a different perspective: "It does if you use SIGHUP."
• Flux159 sought comparison with s6: "How does this compare to s6? I recently used it to setup an init system in docker containers & was wondering if nitro would be a good alternative (there's a lot of files I had to setup via s6-overlay that wasn't as intuitive as I would've hoped)."
• nine_k contrasted s6 with runit and nitro: "S6 is way more complex and rich. Nitro or runit would be simpler alternatives; maybe even https://github.com/krallin/tini."

Use Cases of Init Systems in Containers

A significant portion of the discussion addresses the practicalities and philosophies of using init systems within containerized environments.

• andrewstuart2 expressed a common sentiment: "I'm always torn when I see anything mentioning running an init system in a container. On one hand, I guess it's good that it's designed with that use case in mind. Mainly, though, I've just seen too many overly complicated things attempted (on greenfield even) inside a single container when they should have instead been designed for kubernetes/cloud/whatever-they-run-on directly and more properly decoupled." They concluded, "It's probably just one of those 'people are going to do it anyway' things. But I'm not sure if it's better to 'do it better' and risk spreading the problem, or leave people with older solutions that fail harder."
• mikepurvis offered context from the robotics space: "From my experience in the robotics space, a lot of containers start life as 'this used to be a bare metal thing and then we moved it into a container', and with a lot of unstructured RPC going on between processes, there's little benefit in breaking up the processes into separate containers. Supervisor, runit, systemd, even a tmux session are all popular options for how to run a bunch of stuff in a monolithic 'app' container."
• yjftsjthsd-h questioned the popularity of docker+systemd: "Did docker+systemd get fixed at some point? I would be surprised to hear that it was popular given the hoops you had to jump through last time I looked at it."
• mikepurvis clarified: "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."
• palata offered a critical view on container usage in robotics: "My experience in the robotics space is that containers are a way to not know how to put a system together properly. It's the quick equivalent of 'I install it on my Ubuntu, then I clone my whole system into a .iso and I call that a distribution'."
• bityard emphasized the need for a proper init at PID 1 in containers: "Yes, application containers should stick to the Unix philosophy of, 'do one thing and do it well.' But if the thing in your docker container forks for any reason, you should have a real init on PID 1."
• pas and MyOutfitIsVague discussed the common issues with PID 1 in containers, particularly zombies and signal handling when the primary process isn't designed to be an init system. MyOutfitIsVague stated, "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." dathery added, "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)."

tini and the Role of a Minimal PID 1

The utility tini emerged as a relevant point of comparison for minimal init systems, especially for containerized workloads.

• nine_k mentioned tini as a simpler alternative to s6: "Nitro or runit would be simpler alternatives; maybe even https://github.com/krallin/tini."
• MyOutfitIsVague recommended reading tini's readme for details on its function in handling PID 1 responsibilities in containers.
• lrvick introduced nit, a similar system written in Rust, contrasting it with tini: "Yep. The less C code in production the better." and "Of note, it also will handle platform specific bring-up system calls, basic filesystem setup, etc, so it is much more suitable for embedded, server, or enclave use cases than tini, imo. It is mostly used for Nitro enclaves today."
• nine_k summarized nit's function: "So it's basically like tini (keep a single executable running), but in Rust?"

Naming Conflicts and Project Identity

A practical concern raised was the potential for naming conflicts, particularly with AWS's "Nitro" system.

• axlee advised: "I'd recommend changing names, nitro is already a semi-popular server engine for node.js https://nitro.build/"
• nine_k offered a general naming philosophy: "Any well-known generic word is very likely to already have been used by a bunch of projects, some of them already prominent. By now, the best project name is a pronounceable but unique string, for ease of search engine use."
• lrvick echoed the concern: "I use tiny init systems regularly in AWS Nitro Enclaves. Having the enclave and init system both named nitro is not ideal."
• stonogo downplayed the conflict: "I don't foresee any problems. One is an init system anyone can use and the other one is an internal corporate KVM fork nobody else cares about."

System Design Philosophy and Declarative vs. Imperative Configurations

The discussion touched upon broader philosophies of system design, including the benefits and drawbacks of declarative dependency management.

• Flux159 asked for heuristics on which init system works best for specific use cases, mentioning dependency management and logging needs.
• ItsHarper pointed out dinit as another option with dependency support.
• ethersteeds questioned the selling point of "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."
• nine_k elaborated on Nitro's dependency handling: "Nitro does not declaratively handle service dependencies, you cannot get a neat graph of them in one command. You can still request other services to start in your setup script, and expect nitro to wait and retry starting your service when the dependent service is running." They also noted a drawback: "it's easy to forget to require the shutdown of the dependent services when your service goes down, and there's no way to discover it using a nitro utility."
• Ericson2314 highlighted the advantages of declarative systems in the context of NixOS: "If I my plug my friend and colleague's work, https://nixos.org/manual/nixos/unstable/#modular-services has just landed in Nixpkgs. This will be a game changer for porting to NixOS to new init systems, and even new kernels. So, it's good time to be experimenting with things like Nitro here!"

Documentation and Usability

The quality of documentation and the ease of use were recurring points of discussion, particularly in relation to runit and systemd.

• imiric expressed a desire for better documentation and UI: "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 acknowledged runit's documentation shortcomings: "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."
• kccqzy commented on systemd's documentation: "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."

The "Init Wars" and System Evolution

Near the end of the discussion, there was a reflection on past debates about init systems and the path forward.

• J_McQuade fondly recalled runit: "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." They then contrasted it with their positive experience with systemd on more recent projects.
• nine_k provided a nuanced view on the systemd backlash, attributing it to early rough edges and its broad scope: "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." They also criticized its anti-Unix approach for large organizations.
• CartwheelLinux evoked nostalgia: "Bring back the init wars! /S I got into Linux right before the init wars, and while they were hectic times they brought a lot of attention, discussions, and options to Linux."