SysVinit 3.09 Now Allows Building With musl C Library, Passing Boot Messages To Firmware

[caligula]

At least OpenRC (Gentoo, Artix) and runit (Void) work very well for me, don't know about the others. Tried s6 (Obarun), couldn't quite get my head around it.

If runit/void works for you, it just tells that you don't have notable requirements for an init system. The last time I tried void, it didn't even have any concept of service dependencies. Init files had sleep delays to force a certain sequential order. It's pretty error prone and inefficient. Sure it kind of works, but why would you want that.

[Quackdoc]

Now you made me curious What exactly do you need it to do? I never quite understood how this init-system-frenzy started in the first place; for me they just work (even systemd works for starting services, it's all the other things it does that bother me). Sure, sometimes you have to do some trick to fix start-up order or something, depending on the mix of services you have. I don't think it's possible to have an init-system that can guess how *everybody* wants the system to behave and always do it "right" (by each and every possible user-defined "right").

I only need a basic init system/service manager that isn't a headache, honestly if systemd wasn't so... everything it would be fine for me, ofc low overhead is preferred. but I have issues with systemd doing anything and everything it can and breaking when I try to replace "core" functionality that has nothing to do with an init system. One example I had was running arch in a container, running wayland didn't work because of systemd's udev implementation is garbage, but replaceing udev with libudev-zero + mdev just kind of worked until it nuked itself and started to crash even after updating the two things in question.

I also remeber having login management issues with systemd, I can't remeber what it was. But it's just a series of really annoying issues that all fall under the various "systemd" stuff. And its gotten to the point where just ripping out systemd entirely is much less of a headache.

[rrveex]

If runit/void works for you, it just tells that you don't have notable requirements for an init system. The last time I tried void, it didn't even have any concept of service dependencies. Init files had sleep delays to force a certain sequential order. It's pretty error prone and inefficient. Sure it kind of works, but why would you want that.

You don't need sleep, you just have to "not start until the dependency started"

https://smarden.org/runit/dependencies

At some point, when you have "notable requirements for an init system" (whatever those might be), you have to use some trick to get it right; the trick will obviously differ depending on the chosen init-system and your specific service blend. No big deal. There is no "just press this button and everything will just work" (and never will be)

[bnolsen]

If runit/void works for you, it just tells that you don't have notable requirements for an init system. The last time I tried void, it didn't even have any concept of service dependencies. Init files had sleep delays to force a certain sequential order. It's pretty error prone and inefficient. Sure it kind of works, but why would you want that.

I believe s6 is supposed to be a more complete init solution with dependency support, although I've never looked into it. For my desktops I'm happy with runit but I realize it's not a perfect solution. I don't think systemd is a good solution.

[rrveex]

[...]
I have issues with systemd doing anything and everything it can and breaking when I try to replace "core" functionality that has nothing to do with an init system. One example I had was running arch in a container, running wayland didn't work because of systemd's udev implementation is garbage, but replaceing udev with libudev-zero + mdev just kind of worked until it nuked itself and started to crash even after updating the two things in question.

I also remeber having login management issues with systemd, I can't remeber what it was. But it's just a series of really annoying issues that all fall under the various "systemd" stuff. And its gotten to the point where just ripping out systemd entirely is much less of a headache.

You're fortunate! Last time I tried systemd, I had things like occasional lags when doing just a `ls` or `cd`. Finally gave up when it wouldn't boot any longer, complaining the root partition were faulty, even though it was perfectly fine when I checked it from "outside".

[oiaohm]

I only need a basic init system/service manager that isn't a headache, honestly if systemd wasn't so... everything it would be fine for me, ofc low overhead is preferred. but I have issues with systemd doing anything and everything it can and breaking when I try to replace "core" functionality that has nothing to do with an init system. One example I had was running arch in a container, running wayland didn't work because of systemd's udev implementation is garbage, but replaceing udev with libudev-zero + mdev just kind of worked until it nuked itself and started to crash even after updating the two things in question.

This is most likely you got yourself into big trouble because you attempted to take an incorrect short cut by using a prebuilt arch systemd when you need embedded systemd custom builds that arch does not have. Systemd the source can in fact be built without udev you find this in embedded distributions with systemd. Arch build of systemd is built with udev support enabled. This include different hot plugging for mounting inserted drivers and the like that depends on udev being there and access internal udev things.

libudev-zero breaks systemd without rebuilding it not to use udev because its truly not udev compatible enough. libudev-zero has issues with pipewire and other things for the same things that cause it trouble with systemd where different functions you can do with the real libudev and udevd don't work.. Systemd does have the option when building form source to build without udev support at all of course particular features go away.

Please note I am not saying udevd is bug free here. The issue is neither is libudev-zero there are particular bits of software that are not safe to use with it. Yes systemd is one of those things. In fact libudev completely missing would have had systemd behave better than using libudev-zero.

One thing to attempt to replace core functionality is another thing to attempt to replace something that is a incompatible implementation then complain when things go south. Systemd being lock stepped with udevd means that they expect to use the latest udevd functionality if libudev library is provided this means you are doomed using something like libudev-zero that not going to be upto date enough to work with systemd as it updates.

Embedded developers since 2016 have been using systemd without udev and with mdev instead. Yes embedded developers have not been using libudev-zero just remove udevd and it libudev library completely for systemd. libudev-zero need to be placed in optional path so that systemd does not use it if you want to use it with other applications..

[Nozo]

systemd on musl when

[Blademasterz]

systemd on musl when

not musl friendly lol (uses a lot of patch to get it works), but it is possible on Gentoo

[mxan]

Is upstart still maintained or in a working state? That was the "modern" init system designed to be compatible with sysvinit scripts while also being asynchronous. It was favored, until Red Hat released systemd... and we all know everybody goes with whatever Red Hat chooses lmao.

Upstart is maintained now by... guess who... Google, because it's the init system for Chrome OS.

Red Hat used Upstart in Fedora 9-14 and RHEL 6. Upstart had numerous design flaws but Red Hat didn't want to fix them because Upstart had a CLA, so they made their own init *without* a CLA. No CLA is what let it gain involvement from other people early on - people seem to forget that 1) Ubuntu and Fedora (and RHEL 6) were the *only* major distros that used Upstart by default, and 2) openSUSE and Arch were the first major distros after Fedora to switch to systemd, both in 2012; just a year after Fedora did. No CLA is also a major reason why systemd won over Upstart for Debian in 2015.

TL;DR systemd won because it was quite literally just better.

Also, it's funny how people scream about Red Hat "controlling" systemd when, thanks to there being no CLA, they quite literally do not control it. Canonical, on the other hand, actually *did* control Upstart...

[Quackdoc]

Upstart is maintained now by... guess who... Google, because it's the init system for Chrome OS.

huh, I thought chromeOS dropped it for some reason. Interesting that they still maintain it