Nitro: A tiny but flexible init system and process supervisor

[nine_k]

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.

[J_McQuade]

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.

[smartmic]

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.

[fbarthez]

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

[imiric]

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.

[ethersteeds]

> 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.

[andrewstuart2]

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.

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.

[bityard]

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.

[mikepurvis]

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.

[simonw]

I've used several hosting providers that charge by the container - Fly.io and Render and Google Cloud Run.

I often find myself wanting to run more than one process in s container for pricing reasons.

[Ericson2314]

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!

[stock_toaster]

It will be interesting to compare this to dinit[1], which is used by chimera-linux.

Giving the readme a brief scan, it doesn't look like it currently handles service dependencies?

[1]: https://github.com/davmac314/dinit

[nine_k]

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. To get a nice graph, you can write a simple script using grep. OTOH 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.

[hippospark]

I used dinit in Artix Linux. It is lightweight and impressive (https://artixlinux.org/faq.php)

[runako]

The name & function overlap with AWS Nitro is severe:

https://docs.aws.amazon.com/whitepapers/latest/security-desi...

[stonogo]

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.

[LeFantome]

Name yes but an init system and a hypervisor are pretty different.

[Flux159]

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]

S6 is way more complex and rich. Nitro or runit would be simpler alternatives; maybe even https://github.com/krallin/tini.

[lrvick]

At Distrust, we wrote a dead simple init system in rust that is used by a few clients in production with security critical enclave use cases.

<500 lines and uses only the rust standard library to make auditing easy.

https://git.distrust.co/public/nit

[nine_k]

Likely neat (33% larger than nit), but the readme only explains how to build it, not its interface or functioning.

[usr1106]

I wrote my own init system in C from scratch some 13 years ago. It was more work than anticipated by myself and the manager who approved it. It served the purpose to bring up a Linux GUI and some backend for it on not so capable hardware in n seconds (don't remember n, but it was impressive).

It was a nice programming exercise. Wouldn't be suprised if even back then something like that already existed and the whole effort just demonstrated a lack of insight of what is readily available.

Probably the code still exists on some backup I should not have. Have not looked back and don't know... The company who owned the rights has gone out of business.

Edit: After typing this it came to my mind a colleague of mine wrote yet another init in the same company. Mine had no dependencies except libc and not many features. The new one was built around libevent, probably a bit more advanced.

[awestroke]

An init system without the ability to specify dependencies? Without user/group configuration? Ordering must be manually configured? No parallel service launching? No resource management?

Please don't call this an init systern. It's a barebones process supervisor.

[beagle3]

It actually does all these things. Quite well, even - in my experience better than systemd.

I didn’t use nitro, I’ve been using daemontools (which nitro is an evolution of) for decades. Incredibly easy to use, incredibly stable, understand, and control.

There is no well defined way to do dependencies (what if your dependency dies 3 seconds into the process? There are many right answers). The djb/daemontools way is just “it’s your problem. But here are the reliable simple cheap tools to start, stop and monitor your dependencies”.

[pdmccormick]

I love projects like these. They touch upon so many low level aspects of Unix userlands. I appreciate how systemd ventured beyond classical SysV and POSIX, and explored how Linux kernel specific functionality could be put to good use. But I also hope that it is not the last word, and that new ideas and innovations in this space can be further explored.

Recently I implemented a manufacturing-time device provisioning process that consisted of a Linux kernel (with the efistub), netbooted directly from the UEFI firmware, with a compiled-in bundled initramfs with a single init binary written in Go as the entire userland. It's very freeing when the entire operating environment consists of code you import from packages and directly program in your high level language of choice, as opposed to interacting with the system through subprocesses and myriad whacky and wonderfully different text configuration files.

[GuinansEyebrows]

love to see new init projects. how does it stack up against runit (the last one i really familiarized myself with on void linux)?

[kragen]

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.

[garganzol]

I am interested in using it as a process supervisor in server docker containers. It is clear that it can be compiled from sources, but something like vuxu.org/nitro/install.sh would be super helpful.

[networked]

GitHub repository with the issue tracker: https://github.com/leahneukirchen/nitro.

[zoobab]

Does it require Pid1?

[CartwheelLinux]

Bring back the init wars! /S

Username relevant...

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.

[axlee]

I'd recommend changing names, nitro is already a semi-popular server engine for node.js https://nitro.build/

[nine_k]

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. Ironically, "systemd" is a good name in this regard, as are "runit" or even "s6".

[mperham]

I think I would have gone with nitr0.

[petre]

One of the hard things in computer science: naming things.