It's looks absurdly simple, but works very well. (Speaking as a long-term Void Linux user.)
Configuring a new service is also trivially simple.
Dependencies sort of can be handled: you can start (or stop) another service from within your service; runit will retry if your service fails to start due to a dependency not yet running.
I've had various issues installing Void so I succumbed to Manjaro, which works surprisingly well. I have noticed in general that many non-systemd distributions work less well over time for some reason. Slackware is the best example - one release per decade means it is factually dead, but even trying more modern variants simply no longer works as it once used to work. At the same time there is less and less adapted documentation to be found. It seems the non-systemd distributions not only declined in absolute numbers but also in regards to manpower and time investment. MX Linux also lags behind updating versions of numers programs: https://distrowatch.com/table.php?distribution=mx - it has gotten a bit better after libretto, but it still lags behind compared to e. g. Fedora.
I've done small embedded Linux systems and it makes me so happy that there is a (mostly) compatible implementation built into busybox. svlogd's rotation and size capping makes it great when using limited-lifespan nonvolatile storage like eMMC.
I do the same thing, although as "embedded" systems get bigger I've moved some things over to systemd.
It's a little complicated to set up if your root file system is read-only, since runit really wants to write to the disk, and you must set up symlinks pointing to tmpfs.
I know some people frown on having multiple processes within a container but there are scenarios where it is needed. I've used both openrc and runit for that purpose and runit has been the simplest to setup and use.
this is probably one of the most promising candidates for an init system aside from systemd, right? I know openrc is still having trouble with parallel startups as a result of its design which is almost a must at this point. s6 is in the works from what I hear, but not configurable via simple config files yet.
I made https://github.com/andrewbaxter/puteron/ ! It's more similar to systemd in that it has a dependency graph, but I think it's simpler to use and better aligned with typical use cases. I haven't used it as a full init system though, only on top of systemd (same as I've seen runit used).
Systemd isn't merely an init system though, so I always find these comparisons unfair.
They should focus on one simple and good alternative to the startup-functionality for non-systemd infected systems though. Void has one advantage: they have many clever people, a bit like how Arch used to be before they succumbed to systemd (today's arch is different from when Judd was in charge).
systemd scales. I love small init systems but systemd is just so convenient. It handles daemon process, encryption with cryptsetup, boot process (systemd-boot), hardening options you can define on unit files, good support for nested containerization etc. It's deeply entrenched in every major distro that it's impossible to administer a linux system without it
The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.
As a long-time runit user, systemd does far better with sequencing things. With runit you have to have a check executable, and then run
'sv check servicename' in the start script of the service which depends on another.
Well - the systems presented here are about the init part, not anything else. Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair. If you compare 5_000 lines of code to 500_000 lines of code, the comparison won't work. Systemd assembled numerous things (weed-collection via systemd-homie, for the home setup and I think you can also accidentally delete your home directory, with the systemd devs claiming this is a feature). None of those "features" listed is what I consider needed or necessary. All daemon-startup I already did via ruby as wrapper over the underlying system. For a campus site with many computers, systemd simplified managing them. I don't really see the same benefit for people who know more about computer systems at home - all the complexity is a trade-off with regard to having to learn, understand and apply what systemd brings to the table.
"It's deeply entrenched in every major distro that it's impossible to administer a linux system without it"
That's a non-sequitur, aka an after-the-fact claim made. Not every distribution transitioned into forcing systemd onto everyone - granted, the majority did, but you can find distributions that did not surrender user's rights here, be it devuan, slackware, void, gentoo (https://wiki.gentoo.org/wiki/Gentoo_without_systemd). But admittedly it takes more effort than going into systemd. Note that many of the statements made there such as "hardening options", is just buzzword promo for systemd. It just means nothing. What should "hardening" even mean? Also, it is perfectly fine to use linux on a non-systemd system. People used to do this for decades before systemd infected the linux world. It's a smaller crowd though compared to systemd-using systems and users indeed nowadays.
> ... granted, the majority did, but you can find distributions that did not surrender user's rights here...
I really don't like the phrasing of this. Nobody's rights are being "infringed" by distros going with systemd. Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.
> Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair.
The real argument about systemd is whether you want an init system, or what is effectively an additional layer in the OS. It provides more standardisation, vs more diversity. The strongest argument for systemd is that it is not just an init system, which is also the strongest argument against systemd.
What a cope. The hardening options highly restrict the unit files from accessing anything more than it's required for it's function. systemd has also made a lot of efforts in progressing the boot security: https://0pointer.net/blog/brave-new-trusted-boot-world.html. Have fun running your "non-infected" systems which is so easy to pwn
It's looks absurdly simple, but works very well. (Speaking as a long-term Void Linux user.)
Configuring a new service is also trivially simple.
Dependencies sort of can be handled: you can start (or stop) another service from within your service; runit will retry if your service fails to start due to a dependency not yet running.
I'm a huge fan of Void as well. Surprised it didn't get a mention in the article. I didn't even realize that runit had an existence outside of Void.
I've had various issues installing Void so I succumbed to Manjaro, which works surprisingly well. I have noticed in general that many non-systemd distributions work less well over time for some reason. Slackware is the best example - one release per decade means it is factually dead, but even trying more modern variants simply no longer works as it once used to work. At the same time there is less and less adapted documentation to be found. It seems the non-systemd distributions not only declined in absolute numbers but also in regards to manpower and time investment. MX Linux also lags behind updating versions of numers programs: https://distrowatch.com/table.php?distribution=mx - it has gotten a bit better after libretto, but it still lags behind compared to e. g. Fedora.
5 replies →
Gitlab also uses runit for service supervision.
I've done small embedded Linux systems and it makes me so happy that there is a (mostly) compatible implementation built into busybox. svlogd's rotation and size capping makes it great when using limited-lifespan nonvolatile storage like eMMC.
I do the same thing, although as "embedded" systems get bigger I've moved some things over to systemd.
It's a little complicated to set up if your root file system is read-only, since runit really wants to write to the disk, and you must set up symlinks pointing to tmpfs.
I know some people frown on having multiple processes within a container but there are scenarios where it is needed. I've used both openrc and runit for that purpose and runit has been the simplest to setup and use.
I am here to enjoy systemd vs alternatives comments...haha
goodness that’s a lot of ads
this is probably one of the most promising candidates for an init system aside from systemd, right? I know openrc is still having trouble with parallel startups as a result of its design which is almost a must at this point. s6 is in the works from what I hear, but not configurable via simple config files yet.
I made https://github.com/andrewbaxter/puteron/ ! It's more similar to systemd in that it has a dependency graph, but I think it's simpler to use and better aligned with typical use cases. I haven't used it as a full init system though, only on top of systemd (same as I've seen runit used).
Systemd isn't merely an init system though, so I always find these comparisons unfair.
They should focus on one simple and good alternative to the startup-functionality for non-systemd infected systems though. Void has one advantage: they have many clever people, a bit like how Arch used to be before they succumbed to systemd (today's arch is different from when Judd was in charge).
The best challenger to systemd in terms of feature parity is probably dinit: https://davmac.org/projects/dinit/
Have a look at Chimera Linux if you want to give it a try: https://chimera-linux.org/
runit, s6, and OpenRC don't have the downsides of systemd, but they also only cover a subset of its features
dinit is, imo, the one I'd pick. It's focused but it has dependencies and the services are defined by a DSL rather than startup scripts.
Having said that, I haven't used runit and from the look of it, it's a big improvement over SystemV at the very least.
systemd scales. I love small init systems but systemd is just so convenient. It handles daemon process, encryption with cryptsetup, boot process (systemd-boot), hardening options you can define on unit files, good support for nested containerization etc. It's deeply entrenched in every major distro that it's impossible to administer a linux system without it
The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.
I'm okay with it for comparison's sake.
As a long-time runit user, systemd does far better with sequencing things. With runit you have to have a check executable, and then run 'sv check servicename' in the start script of the service which depends on another.
Least sane systemd hater, try using runit or sysvinit on a production system and come back crying when your runit bash scripts fail all the time
1 reply →
Well - the systems presented here are about the init part, not anything else. Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair. If you compare 5_000 lines of code to 500_000 lines of code, the comparison won't work. Systemd assembled numerous things (weed-collection via systemd-homie, for the home setup and I think you can also accidentally delete your home directory, with the systemd devs claiming this is a feature). None of those "features" listed is what I consider needed or necessary. All daemon-startup I already did via ruby as wrapper over the underlying system. For a campus site with many computers, systemd simplified managing them. I don't really see the same benefit for people who know more about computer systems at home - all the complexity is a trade-off with regard to having to learn, understand and apply what systemd brings to the table.
"It's deeply entrenched in every major distro that it's impossible to administer a linux system without it"
That's a non-sequitur, aka an after-the-fact claim made. Not every distribution transitioned into forcing systemd onto everyone - granted, the majority did, but you can find distributions that did not surrender user's rights here, be it devuan, slackware, void, gentoo (https://wiki.gentoo.org/wiki/Gentoo_without_systemd). But admittedly it takes more effort than going into systemd. Note that many of the statements made there such as "hardening options", is just buzzword promo for systemd. It just means nothing. What should "hardening" even mean? Also, it is perfectly fine to use linux on a non-systemd system. People used to do this for decades before systemd infected the linux world. It's a smaller crowd though compared to systemd-using systems and users indeed nowadays.
> ... granted, the majority did, but you can find distributions that did not surrender user's rights here...
I really don't like the phrasing of this. Nobody's rights are being "infringed" by distros going with systemd. Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.
2 replies →
> Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair.
The real argument about systemd is whether you want an init system, or what is effectively an additional layer in the OS. It provides more standardisation, vs more diversity. The strongest argument for systemd is that it is not just an init system, which is also the strongest argument against systemd.
What a cope. The hardening options highly restrict the unit files from accessing anything more than it's required for it's function. systemd has also made a lot of efforts in progressing the boot security: https://0pointer.net/blog/brave-new-trusted-boot-world.html. Have fun running your "non-infected" systems which is so easy to pwn
2 replies →
Why does every article on runit have some reactionary runit haters in the comments.
The systemd project and its following can be quite cult-like, towards the more devout-end.
[dead]