4.7 KiB
Back to the top joborun wiki page
How to setup runit init and services in joborun
Void's and Artix wikis on runit are pretty complete and relevant, we will only focus here on our own differences. For generaral use of runit see the links in the #References section.
Introduction
runit is a suite of tools which provides an init (PID 1) as well as daemontools-compatible process supervision framework, along with utilites which modify the organization of services and daemons.
In our implimentation of runit we have made a few different choices to accomodate other needs. One is the aim to make a full runit setup coexist with s6/66. In this respect the 4 power functions (halt, poweroff, reboot, shutdown) have been moved to /usr/bin/run/ while the corresponding 66 functions have moved to /usr/bin/s6. To correct the functionality 4 of our own power scripts have been placed in /usr/local/bin/ with the same names, and independent of what the init is (runit or s6) the system will start the correct process. In addition, runit's pointer /sbin/init has been removed and in either grub or syslinux a parameter (init=/usr/bin/runit-init) will be required to start the system with runit. This is the default configuration in our grub setup. When and if 66/s6 bundle is added the parameter definig the init can be removed as 66 will store its own /usr/bin/init which is the kernel's default.
So one boot entry with init=/usr/bin/runit-init boots the system with runit one without boots s6/66.
Furthermore, as s6/66 respect the sys-admin and allow for custom work to be done within the etc ecosystem, particularly /etc/66, we have decided to leave /etc/runit/sv alone for the sys-admin to be creative. Our bundle of service scripts has been placed in /usr/lib/runit/sv to be either linked directly to /etc/runit/runsvdir/default or copied to /etc/runit/sv where they can be customized. Future packagin changes will not affect the /etc/runit/sv contents. The only exception to the rules are the tty definitions that are owned by runit and runit-rc and will remain in this default location /etc/runit/sv/.
Last, we have made no changes to the stage 1 contents and setup. Just like artix and very similar to void's setup, anything affecting runit's stage 1 can be found in /etc/rc where 1,2,3 are defined.
If for some odd reason you make the decision to never use s6
begin note: .... and since linux/unix should be about having choices about all aspects of the system, you can make a hard link to /sbin/init for /usr/bin/runit-init and then edit your boot loader (example grub:/etc/default/grub and remove the extra tag of init=/usr/bin/runit-init )
cd /usr/bin ln -sf /usr/bin/runit-init init
In the same respect, if some day in the future you decide to install s6/66 suite, this link will present a conflict, so remove it again. init=/usr/bin/66-boot in boot-loading will be the same as its default link, only it will run in a sh environment and not in its native execlineb
.... end of note
To enable and start a service/daemon
Let us take dhcpcd as an example:
The service scripts for dhcpcd are stored in /usr/lib/runit/sv The directory that runit parses to supervise services is /etc/runit/runsvdir/default
As root:
% ln -s /usr/lib/runit/sv/dhcpcd /etc/runit/runsvdir/default/
This enables and starts starts the service "under the supervision of runit's runsvdir".
To stop it and disable the same service as root:
% rm /etc/runit/runsvdir/default/dhcpcd
This is how simple things are. You link the service scripts to the catch-all runsvdir directory and runit starts and supervises its running (one shot services are executed once per session).
Services and service scripts
As we don't promote handholding and system administration from above, the existence of runit service scripts don't come with their corresponding dependencies, with the exception of dhclient, wpa_supplicant, ntp, and dbus, which are part of the base package. For all other services to actually run, not only do you have to link the service file to runsvdir, you must also install the corresponding package that is run by the service manager. In other words, if you want sddm as a display manager, the service script is there and you can enable it, but you must also install sddm itslef.
References: