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)
