this post was submitted on 26 Aug 2025
30 points (78.8% liked)

Linux

12824 readers
59 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 2 years ago
MODERATORS
MigratingtoLemmy@lemmy.world
30
Hate Systemd? A New Init System(Nitro) Debuts as a Minimalist Process Supervisor for Linux (github.com)
submitted 4 days ago by Pro@programming.dev to c/linux@lemmy.world
31 comments fedilink hide all child comments
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] chameleon@fedia.io 4 points 3 days ago

scripts mix configuration with logic and this was a big reason why a lot of distributions switched to systemd in the first place

What was really wrong with the old BSD-style rc/init systems is that they mixed configuration with the logic required to start/stop the service at all, and that that logic was running in the same session it was being executed from (inheriting the environment, FDs and the like). These daemontools-style supervisors don't have that problem, the run script is essentially just systemd's ExecStart= and it gets forked off from the supervisor itself and is then managed by it. Lots of them are just #!/bin/sh \n exec coolservice.

There's plenty more things that systemd does pretty well that this doesn't do (dependency management seems to be sorely lacking here in particular), but this kind of approach is much closer to it than the old rc scripts.