Comment by nine_k

Comment by nine_k 21 hours ago

24 replies

View on Hacker News

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 16 hours ago

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.

Reply View 14 replies
  • rendaw 4 hours ago

    I made a process supervisor, probably less simple than nitro but much more simple (and focused) than systemd.

    Aside from the overreach, I think there are some legitimate issues with systemd:

    - It's really hard to make services reliable. There are all sorts of events in systemd which will cause something to turn off and then just stay off.

    - It doesn't really help that the things you tell it to do (start/stop this service) use the same memory bits as when some dependency turns something on.

    - All the commands have custom, nonstandard outputs, mostly for human consumption. This makes it really hard to interface with (reliably) if you need to write tooling around systemd. Ini files are not standardized, especially systemd's.

    - The two way (requires, requiredby) dependencies make the control graph really hard to get a big picture of

    FWIW here's mine, where I wrote a bit more about the issues: https://github.com/andrewbaxter/puteron/

    Reply View 0 replies
  • nine_k 14 hours ago

    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. (Btrfs, released at about the same time, took even longer to stop being imprudent to use in production.)

    On the other hand, systemd replaces Unix (sort of like Hurd, but differently). It grabs system init, logging, authentication, DNS, session management, cron, daemon monitoring, socket activation, running containers, etc. In an ideal Red Hat world, I suppose, a bare-metal box should contain a kernel, systemd, podman, IP tools, and maybe sshd and busybox. This is a very anti-Unix, mainframe-like approach, but for a big consulting firm, like Red Hat / IBM, it is very attractive.

    Reply View 8 replies
    • mickeyp 13 hours ago

      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.

      Reply View 2 replies
      • overfeed an hour ago

        > DNS: Can you from memory recite how name lookups work on Linux

        Yes, I can, and I use systemd only because it's the default on debian, I have no reason to try devuan yet.

        > ever written the old sysV ones from scratch?

        Many, many times, and I was only an enthusiast/user, not a sysadmin.

        > did you remember to make yours re-entrant?

        Dealing with PID files was only mildly annoying. Init scripts were very boilerplate-y, so I wouldn't forget anything after my copy-paste-edit-delete unnecessary parts cycle. In a single afternoon, one could bash out an CLI init-script generator that uses jinja2 templates and interactively asking <10 questions about the service.

        > Systemd is not perfect. But what it replaces was god-awful and far worse.

        Init systems shouldn't have anything to do with managing container lifecycles beyond managing the container-runner service using the usual unix interface (signals). Call me a purist, but system services shouldn't be containerized.

        An init system shouldn't be managing DNS or logging either, those should be standalone components. If they are problematic, there should be composable, domain-specific tools that solve them, instead of smooshing everything into systemd.

        SystemD wasn't the only possible way to solve those logging, DNS, or security policy problems, and I'm glad other PID 1 projects that focus on being init systems are thriving.

        Reply View 0 replies
      • regularfry 2 hours ago

        So one could agree that something should be done, in each of these cases. But that doesn't imply that the thing to be done should have been systemd, or even systemd-shaped. But no, it has borged the lot.

        Reply View 0 replies
    • jcgl 10 hours ago

      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.

      Reply View 0 replies
    • jlarocco an hour ago

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

      Reply View 0 replies
    • adwn 13 hours ago

      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.

      Reply View 1 reply
      • overfeed an hour ago

        > is it desirable for itself, or is it just supposed to be a means to an end?

        It's a means to multiple, desirable ends: first, is that it establishes an interface, which makes developing tooling easier.

        Downstream of well-defined interfaces is that it makes the individual components replaceable - so I can replace the default tool with one written in rust, or a monobinary like BusyBox and everything still works - I doubt the fathers if UNIX ever imagined the idea of BusyBox.

        If the individual components are replaceable, another desirable outcome is achieved: avoiding software monoculture, which is great for security and encourages innovation.

        Reply View 0 replies
    • gf000 4 hours ago

      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)

      Reply View 0 replies
  • MortyWaves 10 hours ago

    The thing I don’t like about systemd is the inexplicable need to have multiple files for a service. Why can’t they all be declared in a single unit file?

    Reply View 2 replies
    • broeng 9 hours ago

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

      Reply View 1 reply
      • MortyWaves 8 hours ago

        All the examples I see is there’s a network unit file, a cron unit file, etc all for one application. It would be nice to colocate.

        Then there is composition of multiple applications too.

        With docker compose I have a single file for running all my services.

        With systemd it has to be N number of files for each service too.

        Reply View 0 replies
  • atoav 7 hours ago

    One of the main issues with systemd (as someone using it everywhere) is IMO that even experienced people can have a hard time understanding from which context a command is running.

    E.g. if you "just" want to automate a script that you were running from a terminal as a user, there can be a ton of problems and it is hard to figure them out ahead of time.

    Reply View 0 replies
fbarthez 8 hours ago

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

Reply View 1 reply
  • cout 7 hours ago

    What I got from looking at that comparison is that runit starts a separate supervisor process for each process started. I like the cleaner process tree of nitro, but I wonder what the tradeoffs are for each.

    Reply View 0 replies
smartmic 20 hours ago

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.

Reply View 0 replies
ethersteeds 14 hours ago

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

Reply View 0 replies
imiric 21 hours ago

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.

Reply View 4 replies
  • kccqzy 14 hours ago

    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.

    Reply View 0 replies
  • nine_k 21 hours ago

    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.

    Reply View 0 replies
  • cbzbc 19 hours ago

    runit doesn't always take care of services it manages in the same way as a proper init . From the man page:

    "If runsvdir receives a TERM signal, it exits with 0 immediately"

    Reply View 1 reply
    • Arch-TK 18 hours ago

      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.

      Reply View 0 replies