Update
* The bug request for requirements for being a pre-dep of init is
#1028115 [1]
About the list of TODO in #923450;
> * If the init system is booted in the most obvious way on a simple TUI
> system (similar to a default Debian install with Priority: standard
> packages), it should start at least one console getty on a VT for
> interactive login, without the sysadmin needing to set this up
> manually.
DONE
The runit-init package depends on getty-run package, that provides six
gettys enabled on /dev/tty[1-6] by default on linux.
> * It should be possible to configure the init system to provide a
> getty
> on a serial console, for testability on headless servers and VMs,
> and it should be documented how to do this.
> (systemd makes this very convenient, by starting a getty on the
> kernel
> console by default, and I would encourage this approach. sysvinit is
> less convenient here, but does at least have a relatively well-known
> way to enable a getty on a serial console.)
The getty-run package also provides a getty-ttyS0 service that is
disabled by default.
TODO: - document how to enable the getty on a serial console or
- enable it by default
>* If the init system is booted in the most obvious way on a simple GUI
> system, it should be possible to start an X11 display manager and log
> in to a simple X11 GUI by merely installing packages, again without
> needing manual setup. I think it's fine to have non-default init
> systems
> that don't satisfy the dependencies of major desktop environments
> like GNOME and KDE (which need systemd-logind, which in turn needs
> systemd), but something like xdm + openbox should always be possible,
> and ideally any desktop environment whose dependencies are met should
> work without further sysadmin intervention.
DONE
even major DE like KDE (and probably also GNOME, but did not tested it)
works; the main problem right now is switching init and installing
elogind without having the DE entirely removed, but this is beyond the
scope of runit-init. Once the user has managed to switch to runit,
things works as expected.
>* If the init system is booted in the most obvious way on a server
> with popular/important server daemons (particularly OpenSSH since
> that's a
> common way to log in, but also things like Apache httpd, Exim,
> Postfix,
> PostgreSQL, dbus-daemon), then those server daemons should work
> correctly without further sysadmin intervention.
DONE
The openssh-server package provides a runit service; other important
services are included in the runit-services package which is now in
testing
> * As a "lowest common denominator" to enable the majority of services
> to work, the init system should be able to run services that are
> defined
> by LSB init scripts, either directly (as sysv-rc does) or by
> translating
> them into its own representation of a service (as systemd does).
DONE
The runit package ships a /lib/runit/run_sysv_scripts script that
starts sysv scripts (S links in rc2) in the right order at boot and
stops sysv scripts at shutdown. A sysv script is skipped when a
native runit scripts with the same basename exists in the system.
This approach is not free from potential bugs [2] but it works as
expected right now
> * It should be straightforward for maintainers of unrelated packages
> to
> boot the init system on a virtual machine for testing. I see that on
> #838480, Martin Pitt suggested an autopkgtest that would codify how
> to
> do this and verify that it works, and I think that's an excellent
> idea.
A runit-init switch autopkgtest called `init-switch' was added in runit
2.1.2-32 and a rule to manually run the test was added in runit
2.1.2-33.
The test installs runit-init and then reboot into it, so both the
init switch and runit boot are tested.
TODO: update the test to include runit-services package.
> * The init system should have a CLI broadly compatible with the common
> interface of sysvinit and systemd: reboot, poweroff, telinit and
> so on. Unfortunately this is mostly defined by Unix folklore rather
> than a formal specification, but comparing the commands provided by
> sysvinit and systemd would be a good starting point, and so would
> comparing each of sysvinit and systemd with the list of executables
> mentioned in the FHS.
>
> I agree with your comment on #838480 that shutdown's time
> specification
> feature is perhaps more complicated than you would want to implement,
> but it might be reasonable to consider implementing it so all time
> specifications other than 'now' are errors?
DONE
The runit-init package ships compatibility symlinks for halt, poweroff,
reboot, shutdown, runlevel.
The runit package ships its own implementation of shutdown that
provides an interface for halt, poweroff and reboot; it's also
capable of talking with the initctl pipe so that an init switch like
systemd --> runit or sysvinit --> runit does not require an hard reset.
The interface is documented in shutdown(8) shipped with runit package.
The runlevel script only prints `N 2' as this is the runlevel
emulated by runit when it runs sysvinit scripts, and this is needed
by some tools like invoke-rc.d .
> * The init-neutral commands in init-system-helpers (invoke-rc.d,
> service,
> update-rc.d) should have their expected functions with the new init
> system: as a minimum, they should be able to register and invoke LSB
> init scripts. Conveniently, init and init-system-helpers are built by
> the same source package.
There was some discussion at #924132/[3] and it was suggested that
runit equivalent of update-rc.d and invoke-rc.d should be kept in
separate bin like deb-systemd-enable and deb-systemd-invoke.
Currently runit-helper and trigger_sv (runit package) both provide
the equivalent functionality of update-rc.d and invoke-rc.d; the main
outstanding problem with these is that they are not guaranteed to be
installed at postrm stage (purge)
TODO: - merge some code fallback for purge into i-s-h, to be called in
postrm when runit-helper/sv_trigger are not installed.
- send updated patch for i-s-h's service and service(8) with runit
support to #924132 [4]
> I don't think that having a mechanism analogous to systemd's
> "shadowing"
> (where a native systemd unit foo.service is used in preference to a
> LSB
> init script /etc/init.d/foo, and is assumed to replace and supersede
> the LSB init script) should necessarily be a requirement, but I do
> think
> it's an excellent idea, and I would encourage its use.
This is done with a /lib/lsb/init-functions.d/40-runit sourced
script, in unstable since runit 2.1.2-50
Also, not on the #923450 list, but relevant
* Detect runit as init with reportbug, done in #913236
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028115
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%231024969
[3]
https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/10
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924132
