cloux
commented
5 years ago Hi, you made some very good points.
the way debian handles runit isn't exactly up to par
Debian uses systemd, and doesn't handle any other init equally. It's very hard to change the init there because of the fair amount of dependencies. That's the reason Devuan, Artix and many others came to being, to provide repos with packages that are not dependent on any specific init.
Sadly, Devuan doesn't handle runit up to par either: see the init metapackage, it pre-depends on (sysvinit-core | upstart). If you want to install runit-init, you have to remove conflicting sysvinit-core, which removes init, which you have to acknowledge by typing exactly "Yes, I am aware this is a very bad idea". Ugly.
On the other hand, runit-init is not handled as being up-to-par because it is not. It's missing runscripts. My runscripts are based on VoidLinux, but now almost completely rewritten and extended. No other distro except VoidLinux provides meaningful runscripts by default. Devuan has just some basic weird stuff, like you said, starting sulogin and a single terminal and that's it.
I much prefer void's method
Same here. VoidLinux makes a simple, elegant and stable impression. And while I appreciate it's packaging system xbps, I mostly prefer the DEB base. That's why I tried to integrate the Void-runit approach into Devuan. It's solid.
I mainly use Artix
That seems like a good distro. If systemd-free Arch base is required, definitely worth a try. However, I never used it so can't comment on it's implementation.
Artix's implementation is a bit odd in its usage of "core-services" or "sv.d" scripts, however. According to one of the maintainers, this is so each phase in the boot process can be "monitored" if it completed successfully or not.
First, "core-services" is a confusing misnomer. The word "core" does not contain much information: almost anything in a computer can be regardes as a "core" component. The word "services" usually describes programs that daemonize and run in the background. But there are NO DAEMONS in the /etc/runit/core-services path, just simple scripts executed sequentially in the first runit stage by /etc/runit/1, or as you correctly called it, the boot process. I renamed the path to /etc/runit/bootup in my repo, to make more evident what's going on.
Second, this stage can be completely and fully "monitored" by bootlogd service, as you suggested above. It took me a while to figure this one out, so let me explain how it works (my repo feature only):
- runit-init starts /etc/runit/1 script
- the first thing this 1 script does: it starts bootlogd (if the service is enabled)
- then starts boot-scripts from /etc/runit/bootup sequentially
- the last boot script 20-autorun.sh executes scripts from /etc/runit/autorun in parallel in the background
- the second stage /etc/runit/2 starts the runsvdir supervisor, which starts the bootlogd service. The bootlogd runscript nicely closes the unsupervised bootlogd started in stage 1, and then continues running bootlogd supervised.
- the third stage /etc/runit/3 then rotates the boot.log file on shutdown.
The logfile of the bootup stage is /var/log/boot.log, and the logfile from the previous boot is /var/log/boot.log.1. The logfiles of the scripts from /etc/runit/autorun/ are saved as /var/log/autorun-SCRIPTNAME.log.
Void takes a much simpler approach, and it seems your implementation essentially copies it with a few changes and additions.
Yes!
For running a desktop, Artix's implementation works perfectly fine, except for bootlogd.
I was primarily targeting cloud deployments, but now I run the same thing on my laptop. It works perfectly fine, including bootlogd. I also included some desktop-only runscripts, like X11dm to start any display manager, or wicd for network management.
Artix... does not generate the bootlog for some god forsaken reason.
Usually there are 2 reasons: either bootlog starts too late, or is missing /dev/pts pseudofs when it starts. Both need to be taken care of very early on, see my stage 1 script. Don't know how to handle this in Artix, or when combined with OpenRC.
I also wonder why bootlogd, udev, and other important start processes are not treated as services in a runsvdir in stage 1 before moving to another runsvdir in stage 2
That would be a bad idea and complicate things. Stage 1 is strictly sequential, runsvdir is for supervising things running in parallel. You want bootlogd started before anything else. You want run udev after the /dev is mounted but before you initialize filesystems or network. The bootup stuff usually has strictly sequential dependencies/precedence, it can't run in a parallel supervisor.
if I remember correctly, switching runsvdirs would kill any services in the previous runsvdir
No. Services present only in the old runsvdir will be closed, services present only in the new runsvdir will start. Services present in both runsvdirs will continue running as if nothing happened.
I wonder if multiple runsvdirs at once is even possible
Unnecessary, single supervisor for all services is sufficient. Again, stage 1 doesn't need supervision. If required, you can start daemons in stage 1 unsupervised, like bootlogd or udevd. Works just fine. You can see udevd here at the bottom, running daemonized outside of the runsvdir process supervisor:
This is because it got started and daemonized early in the 1st stage by /etc/runit/bootup/02-udev.sh. If you enable supervised udevd in stage 2, the udevd runscript automatically takes care of closing the unsupervised instance. Simple, single line of code.
If we keep in contact with the Devuan maintainers, we could possibly get your changes in officially
That would be nice, maybe more people would find runit helpful. My work is here public domain unlicense-type. Do whatever you want, literally, you don't need my blessing.
Now, why not try to get these changes into Debian as well? Well, debian strives to be backwards compatible according to the runit maintainer, but it barely functions on its own with its current implementation anyway.
There is a lot of discussion about this, for years now. I don't want to get into it.
/etc/service is not the wisest place to store running services, since /etc can become readonly
I totally agree. In Devuan, /etc/service/ is a symlink to /etc/runit/runsvdir/default which contains symlinks to supervised services. These symlinks point to service definitions in /etc/sv/. So far so good, it's all configuration, that fits to /etc. BUT: runit then puts its runtime information into _/etc/sv/SERVICENAME/supervise subdirectory!!! That is runtime-dependent variable information, should be e.g. in /var/run and not in /etc. This was done probably to keep the codebase simple, but I see this as a bug or at least as bad practice.
Tank-Missile
I've been following the devuan mailing list and quite a few people are in agreement that the way debian handles runit isn't exactly up to par. I also reported a few problems with the way it was implemented to the debian runit maintainer, such as sulogin being started in stage 1. The getty-run package also had problems with no job control in the shell, but that was rectified. I'm still not 100% happy with the getty scripts though. I much prefer void's method. I mainly use Artix, and fell in love with runit for its simplicity and not doing as you said in the description, "Do everything, do it in PID1". Artix's implementation is a bit odd in its usage of "core-services" or "sv.d" scripts, however. According to one of the maintainers, this is so each phase in the boot process can be "monitored" if it completed successfully or not. Void takes a much simpler approach, and it seems your implementation essentially copies it with a few changes and additions. For running a desktop, Artix's implementation works perfectly fine, except for bootlogd. In fact, bootlogd is quite iffy on Artix, Debian, and even here. In layman terms:
Debian: Uses sysvinit scripts to start system and bootlogd, and then kills bootlogd in rc2.d.
Devuan: Same problems.
Artix: Uses its own "rc" commands but does not generate the bootlog for some god forsaken reason.
I also wonder why bootlogd, udev, and other important start processes are not treated as services in a runsvdir in stage 1 before moving to another runsvdir in stage 2. According to the runit documentation, switching runsvdirs is supported. Then again, if I remember correctly, switching runsvdirs would kill any services in the previous runsvdir. I wonder if multiple runsvdirs at once is even possible then. In any case, this is a great project that shows that runit can work in a debian based distribution without the need for sysvinit scripts for booting. If we keep in contact with the Devuan maintainers, we could possibly get your changes in offficially (don't quote me on that).
Now, why not try to get these changes into Debian as well? Well, debian strives to be backwards compatible according to the runit maintainer, but it barely functions on its own with its current implementation anyway. An overhaul shouldn't be out of the question.
One more thing is the service directory location. /etc/service is not the wisest place to store running services, since /etc can become readonly. In conclusion, I hope to gain more insight from you on this matter.