Package: runit Version: 2.1.2-48 Severity: wishlist X-Debbugs-Cc: plore...@disroot.org
Solutions listed in #1021465 provide access only to sysv service but there are other issues left: 1. can't forward signals from systemd path, socket, timers; even an override of deb-systemd-invoke from i-s-h won't work as calls to deb-systemd-invoke in maintscript are run only when systemd is init. 2. same problem as above for packages that ship a systemd service without a sysvscript counterpart, either because it never existed or because it's been removed 3. the standard upgrade sequence that happens at postinstall, or at prerem and postrm is unfitted for runit design: - in runit, when a service is enabled is also automatically started, and when is disabled is also stopped, no way around it. So doing enable+ start at postinstall and stop + disable at pre|postrm is not just pointless, but can be racy like in #919296 Also, combo like 'enable but don't start' that are possible with debhelper are not feasible in runit. - the standard postinstall ( enable + rescan + start/restart ) sequence is not efficient when more services are involved in the same upgrade, for example if 10 packages with services are upgraded the results is 10*(enable+rescan+start/restart), while a more conveninent sequence could be 10*(enable) + 1*(rescan) + X*(restart), skipping the start of newly enabled service ( to avoid te race) and doing one rescan for the entire upgrade. 4. the one-to-one equivalence between runit and systemd or sysv services is not always feasible and sometimes is undesiderable: - runit does not have a service manager, supervised services are started in parallel and dependencies are automatically sorted out with polling; with this design splitting services into several pieces like systemd does is not a great idea as it makes relation between services more complex to solve - sometimes the opposite is true and one sysv or systemd service has to be expressed with more than one runit services ( for example the ExecStartPost systemd directive) Overall, 1, 2 and 4 can be resolved by merging native runscript into packages but there are other two problems: * during the boot runit first runs all enabled sysv services in rc2.d (skipping when a native one exists), then starts all native services in parallel; so services that are involved in a dependency relationship should be merged in reverse order (otherwise the boot sequence will be broken). For example, before merging dbus runscript, all services that depends on dbus should be merged. This should be done without NMU as support for non default init is a whishlist bug. This is simply not feasible. * there is a social issue with non default init in Debian; a certain group of maintainer will refuse to merge support for other init system. So there is a need for a catch all 'runit-services' package at least for the above two case. As a runit-services package ships only services definition while binaries are in separate packages from other multiple sources, there is no established way to perform the standard maintscripts sequence[1]. This is not just an issue of reduced support for an alternative init: silently omitting to restart a runit service when a new version of the package that ships the binary fixes an outstanding CVE is a bad, probably RC security bug. An optimal solution is one that: * provide enable/disable and restart when the service definition is in a separate package from the one the ships the binary (without cooperation from the latter) * works when there a one-to-one relation with sysv or systemd services is not possible (basically decoupling runit services from other inits) * provide an efficient sequence where services are first enabled/disabled, then runsvdir is told to rescan and finally only services that are upgraded are restarted (decoupled from dpkg configure order) * bonus point if the mechanism can be used by local admin to handle their collection of services without the need to do a deb package Probably it can be done by writing data that is usually in maintscirpt inside some file that is parsed at runtime by a dpkg noawait trigger. This is kind of reinventing the wheel, except that if it works, it's a technical solution to workaround a social problem. Anyway I think this is within the scope of the "experimenting with alternative init" of the last init GR. [1] something like enable/disable the runit service when the package that ships the correspondent binary is installed/removed and restart the service on upgrade -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages runit depends on: ii libc6 2.34-8 ii runit-helper 2.14.2 ii sysuser-helper 1.3.7+really1.4.1 Versions of packages runit recommends: ii runit-init 2.1.2-48 Versions of packages runit suggests: ii socklog 2.1.0+repack-4+b1 pn zsh <none> -- Configuration Files: /etc/default/runit changed [not included] /etc/runit/ctrlaltdel changed [not included] /etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: '/etc/runit/runsvdir/single/sulogin/run' -- no debconf information -- debsums errors found: debsums: changed file /lib/lsb/init-functions.d/40-runit (from runit package) debsums: changed file /lib/runit/trigger_sv (from runit package)