Hi Mercury,

thanks for the guide! as it was said in other posts I haven't found yet the time to write a comprehensive guide/documentation to runit, for several reason:
time constrains of course, but also parts of the runit debian integration are still under development and I prefer to finish before writing a guide (it will be obsolete soon otherwise).
I try to keep manpages up to date though, so I suggest reading

man invoke-run
man update-service
man cpsv

Also I try to keep README files in runit and runit-servics packages up to date

If not installed by default (not sure), I suggest to install apt-listchanges package
to read the NEWS during the upgrade (I do write NEWS when there are important changes)

that said let me add few comments on top of your guide:

this is correct and is the desired end state, however there are still packages (getty-run, openssh-server, acpid, tor, irqbalance and few others)
that are using the legacy layout and install the service directory directly in /etc/sv/ (without metafiles, the legacy runit-helper is used instead of trigger_sv): I still have to organize the transition.

be aware that, as the name may suggest, trigger_sv run as a dpkg trigger at the end of each apt operation (install/remove/upgrade), so the sync happens at runtime; then a sync was added to stage 2 to ensure that the first time you boot runit after an init-switch (sysvinit --> runit-init) the state of services is synched with defaults.
At runtime the trigger loop takes care of enable/disable services, but it also runs the second ("upgrade") loop that make sure that running services are restarted (or reloaded) when their binary is upgraded.
The upgrade loop is very important for security: if the running instance is not upgraded it may still be affected by CVEs while the package changelog claims the issue is fixed..

/etc/runit/2 is a conffile so dpkg will ask at upgrade if you want to keep your version or want to use the package version, no automatic overwrite will happen: but this wont stop the runtime dpkg trigger invocation.

If you want to override something (including metafiles) inside a service directory that is in /usr/share/runit/sv.current , the intended way is
create a copy in /etc/sv/ and maintain it by yourself (it won't be automatically overwirtten at upgrades, and there is no dpkg prompt so you have to import bugfixes by yourself).

(better if runit >= 2.2.0-7 is used for this)
As example for cron, you can do
(make sure there is no /etc/sv/cron dir first)

#cpsv p cron

than you can remove any symlink and replace it with a real file that includes your changes
to inspect the diff later you can do

#cpsv d cron

if you want to override *all* services dir in /usr/share/runit/sv.current then writing copies in /etc/sv/ is no longer practical: the metafiles interface and cpsv are designed to allow to roll your local/private collection in place of services provided by packages, but I haven't tested this myself yet and the operation is dangerous if done at runtime (if a directory disappear from runsvdir directory, the service is stopped, so guess what can happen if you switch the target of symlinks in /usr/share/runit/ the wrong way..) so I won't document it here for now.

Best,
Lorenzo

what verison of runit and runit-services do you have?
Your first post says you are using Daedalus, the fix is in Excalibur (runit-services 0.9.1, runit 2.2.0-3).

(see also my comment in https://bugs.debian.org/cgi-bin/bugrepo … 1092031#84
as you may want to rename the file to avoid harmless but spamming errors in log file)

Lorenzo

Hi Alverstone,

I redirected runsvdir output to /dev/tty10 on my system and  tested  <sysrq>+K on tty1 and it brings down the system;
tested again, and it's actually the

exec <>

that does the trick and shields runsvdir from <sysrq>+K

I should have been more precise, apologise if this wasted your time in search of a solution with a proper log:
what I mean is that it's preferable to not discard completely the runsvdir output by default; it doesn't have to be necessary a proper log file.

since output to tty and exec <> does the trick I think I prefer that to proper fifo.

Issue with the fifo is what happens if the buffer is full and there is nothing reading on the other side, I'm not sure if that can affect runsvdir in a bad way, that would be a problem.
What I fear (more than the race between lines written and runsvdir-log startup) is that a user can disable the runsvdir-log service because he doesn't care and then, due to some service malfunction later, the buffer slowly fills up.
Runsvdir output 1 line per second for each non functional service (example run not executable or not found); how many line it takes before the fifo buffer is full?

On the other hand is hard to predict if a ttyN is available in a system; only thing that is granted to be there is /dev/console (reason why runit outputs there, I think) but /dev/console is connected with tty1, so we are at the starting point..

I agree with the logic you proposed for stage 2 but I prefer something more simple; your proposed code could be fine if I roll runit specific bootscripts but for now I prefer to keep stage 2 more simple. I'm thinking of an hardcoded list of  /dev/* with a fallback on /dev/console;
I think standard system (desktop, laptop, server) have plenty of tty; less sure about embedded hardware (raspberry, arduino or even more essential hardware); there is also the container case to cover.

Something like (recycling you code, simplified)

for out in tty12 ttyS1 tty1 console; do
  if [ -c /dev/"$out" ] ; then
     PIPE="/dev/$out"; break
  fi
done
exec <>"$PIPE" >"$PIPE" 2>"$PIPE"
exec env - PATH="$PATH" runsvdir -P "${SVDIR}"

your code is certainly more configurable from user point of view,
but unfortunately I fear is also more fragile if the user is not aware of the fifo.
let me know if you  see shortcomings or you have more thoughts on this; I intend to
add a fix for this in the next runit upload to unstable.

Thanks for your ideas!
Lorenzo

Hi!

but this discards all output from runsvdir right? Or are you able to get it in some other way?

anyway, clutter tty1 is a known issue, <sysrq>+K is new to me. And there is also this other issue
https://github.com/void-linux/runit/issues/14
reported at Void.

I would like to address them all, and keep a log or runsvdir if possible..

Could you test the following in stage 2

PIPE=/run/runit/runsvdirpipe
mkfifo "$PIPE"
exec <> "$PIPE"

exec env - PATH=$PATH  runsvdir -P "${SVDIR}" >"$PIPE" 2>"$PIPE"

note that the log arg for runsvdir (the dots) is removed.

and a log of runsvdir could be catched with a simple service like (run file)

#!/bin/sh

NAME="runsvdir-log"
LOG=/run/runit/runsvdir-log
test -d "$LOG" || mkdir "$LOG" && chown -R _runit-log:adm "$LOG"

exec 2>&1

exec < /run/runit/runsvdirpipe
echo "Starting runsvdir-log"

exec chpst -u _runit-log svlogd -tt "$LOG"

I tested quickly and it seems to do the job, please let me know if it works for you

Lorenzo

Hi!

Is this is a side effects of the fix for #1038789 ? (not sure)
https://bugs.debian.org/cgi-bin/bugrepo … %231038789

the openrc package is not forked in Devuan, so please report directly to Debian!

Cheers,
Lorenzo

Why? in any case the sysv script is not usable if the binary is not installed. The chmod - x is done for heuristics, for example to be able to tell if the binary is installed and avoid to unecessary call the script if it's not (I'm talking about automatic start/restart that happens in maintainers script during package upgrades)

Not really: the script is automatically chmod +x as soon as you reinstall the package, you don't need to worry about this.  Other tools around initscript (invoke-rc.d, runit's /lib/runit/run_sysv_scripts) were changed to cope with non executable initscripts, openrc was just lagging behind.
Note that debhelper is used at build time to help pkg maintainers to automate the build process, it affects build-time, it doesn't affects runtime.

Lorenzo

it looks like there is a problem with openrc postinstall script, likely a bug. As already mentioned, I know very few about openrc so I don't have an explanation. I suggest you open a bug report on openrc package linking this page

Lorenzo

did you installed also runit-services package?

I don't think dpkg-reconfigure has any use here; reinstall openrc + sysvinit-core should do it.
Then, to reboot from runit into openrc call

/lib/runit/runit-init 6

it was like that (chown -R) but the recursive option was removed due to symlink attacks [1] risk. But anyway I think the underlying issue is that I can't force a change in the log runscript (it's a conffile under /etc/) so there will always be a chance of a mismatch.
I'll drop an entry as NEWS file for runit to warn users.

Lorenzo
[1] For example https://github.com/OpenRC/opentmpfiles/issues/4

Hi Fabien,

There is no support for runit in the service wrapper, but what you are reporting
only happens if
* you have runit installed
* a runit definition for the service exists for example /etc/sv/ssh
* the service is enabled with runit ( /etc/service/ssh link exist )
otherwise the service wrapper should work

I don't recommend this unless you fully understand what it does: it will run the sysv script even if you have an active instance of the same service already managed with runit; possible side effect are:
- crash of the runit instance
- you get two instance running (only one is supervised by runit)
- the reported status of the service may be inconsistent with the one you get with 'sv status'
it also can break the upgrade of few packages - I think it was mariadb ..

The real fix would be to add runit support to the service wrapper, hopefully will happen in this cycle; for the time being I recommend to use the sv command to control services that are managed by runit.

Lorenzo

Hi,

(sv start)  is equal to (sv up + sv check), so the subtle difference is that I'm forcing the wanted status to be 'up' before the check;
as for true vs exit <some_value> I'm using the latter for hard dependency and true for soft dependency. Of course I may have wrongly set a dependency as soft instead of hard..
Do you have a script that doesn't work for your use case? If yes please report it and I'll have a look again.

yes it does: are you running rsyslog with a runit service or as sysv script?

If you use a runit service you may have to add a cronjob with
(assuming that your service is called 'rsyslogd')

sv hup rsyslogd

if you are using the old sysvscript, have a look at /usr/lib/rsyslog/rsyslog-rotate;
recent version of the Debian package are using code that is a noop on non-systemd systems.
if that's the case, you need to create a cron job with

if [ -x /etc/init.d/rsyslog ]; then
    invoke-rc.d rsyslog rotate > /dev/null
fi

I'm not sure if Devuan has it's own version of rsyslog package, but still worth a check