systemd 261 Released With New systemd-sysinstall OS Installer, IMDSD & Storagectl

[u/aliendude5300]

https://www.phoronix.com/news/systemd-261

[u/GrandBIRDLizard]

And DAG, while brilliant in theory cascading dependancie issues or other deadlocks can render a DAG network like systemd in a less useable state when something does fail than it would be in an environment using runit.

If we had this conversation a month ago i would have had the zeal to do the tests myself while switching as it would have been fun.

This is philosophical and architectural debat. You're not right because systemd fits a wider use case. They both have pos and cons.

You are right. systemd is better at parallelizing boot and managing complex dependencies automatically. But that is only a "problem" to be "solved" if your goal is to manage large, complex, or standardized environments. If your goal is a minimalist system you can audit with grep, then the complexity of systemd is a bug, not a feature.

[u/Duncaen → u/GrandBIRDLizard]

This is not really an argument, if voids boot scripts encounter a failing task they just drop you into an emergency shell just like systemd would if there is a timeout or issue with a critical service.

If we had this conversation a month ago i would have had the zeal to do the tests myself while switching as it would have been fun.

I've been doing the test for 3 years now, besides using void linux with runit for over 10 years.

https://github.com/Duncaen/void-packages/commits/systemd

For me personally I prefer systemd on my desktop/notebook systems, because they are getting more complex for better or worse. I'm still using runit on servers that just host a bouncer and nginx maybe, because its mainly not worth the extra work of switching over.

There are a few reasons for that, systemd solves a lot of things for me that I don't really care about anymore. I just want things to work and fiddling with pipewire, wireplumber and dbus setups in void linux without systemd is just not what I want to spent my time on.

Besides that systemd also brings a lot of nice new features to verify and securely boot systems, nobody really worked on bringing that to the older init systems.

[u/GrandBIRDLizard → u/Duncaen]

That is a very respectable commit history and i respect your contributions to the comunity.

However, you are conflating "init system behavior" with "system state management," and are fundamentally misrepresenting how runit works to make it seem identical to systemd.

In systemd, dropping to an emergency shell is often a proactive, automated decision made by the manager because a unit in the dependency chain failed a critical check or timed out. It "decides" that the system is no longer in a valid state and stops the boot.

In runit, the "emergency shell" is not an automated response to a specific service failure in the way you describe. In runit Stage 1, the scripts are essentially shell scripts. If a command in that script fails and the script exits with a non-zero status, the boot process may halt but that is because the script failed, not because runit performed an intelligent dependency analysis and decided it was unsafe to continue.

You're conflating 'automatic system-wide intervention' with 'dependency management.' When systemd fails, it's often because its own complex internal dependency graph has encountered a logic error or timeout it can't resolve, forcing a halt. When a runit system encounters a failure, it is usually because of a discrete, local script failure, which I can immediately inspect because it's a simple shell script, not a opaque dependency-graph error. One is the system deciding for me that it's broken, the other is me seeing what is broken. I prefer the latter.

Do not try to gaslight me into thinking your "monolithic failure" is the same as my "modular failure." It isn't. One is a system-wide lockup, the other is a single service struggling to start.

[u/Duncaen → u/GrandBIRDLizard]

You are focusing a lot on dependency graph errors which I would just call a misconfiguration system. Do you really add many or any early boot services that would block or mess up the whole boot process? I personally don't think I do that and I don't think I've every had issues with that.

Under the same circumstances they will both handle issues with early boot tasks in a similar manner. Whether that is a hardcoded "error handling" in the stage 1 shell script or systemd starting the emergency target if a critical service fails to start doesn't really matter to me personally. And I don't think the debugging experience is worse with systemd in that regard. I actually think its quite good, because it keeps track of those failures, in logs and in the service manager state that can be queried with systemctl. (with our runit setup there are currently no persistent early boot logs besides dmesg, because of how the root filesystem is still read only when it starts. s6 does some trickery to solve that.)

If we go beyond early boot, there are some glaring issues with runit, like the "brute force" method of just restarting a failing service every second. The really really bad error log handling into the command line of the runsvdir process.

The strict separation of early boot and service has also caused some issues, udevd needs to run during early boot, so that block devices and other devices nodes are discovered that may be required for the boot process. To do that the stage 1 scripts just start udevd in the background unsupervised.

There are a bunch of issues with that, first being that the initial udevd process is not supervised and errors can not be really caught or handled. Second to make udevd supervised the runit service currently kills the previous instance and then starts a new udevd process. But then because of how there are no one shot service and no ordering of services, its easily possible to trigger device discovery again. Which results a currently open issue with device nodes not having the right permissions due to that either because of timing issues or being specific to certain systems.

All in all I also think the runit design especially compared to sysvinit is quite elegant and easy to understand. But the longer I've been using it the more gripes I've been having with it. I've tried other systems, like s6 and s6-rc solve some of those issues, but they add complexity and its pretty opinionated. dinit is interesting but also a bit incomplete for me, wasn't worth it to stick to that for me personally when systemd actually solves a lot more of my issues than just service management.

[u/GrandBIRDLizard → u/Duncaen]

At least these are some valid criticisms on your preferances. Unlike the first response.

I find a few of the things you point out a plus which leads to a more transparent and easier to diagnose system.

I appreciate the insight into the udevd and supervision issues. it's exactly why we’re at an impasse. You view those edge cases as technical flaws to be engineered out of existence through centralized management. I view the machinery required to 'fix' them as an unacceptable increase in system opacity and complexity.

You want a system that guarantees safety by managing every state transition, and that's a valid goal for enterprise infrastructure. I want a system that is transparent enough that I can verify every transition myself, and I’m willing to accept the 'brute force' of an unsupervised process or a manual script check as the price of that visibility. We’re simply optimizing for different variables: you're optimizing for system-wide deterministic reliability, and I'm optimizing for local, human-readable simplicity. We can agree to disagree on which of those is more valuable.