The officially official Devuan Forum!

Alverstone

Member

Registered: 2024-10-06

Posts: 21  

Excalibur, runit's supervision tree inherits tty1, misbehavior

<sysrq>+K on tty1 brings the system down. Happens because runsvdir gets SIGKILLed by the kernel. Happens because runsvdir inherits tty1. I think this is a bug and should be fixed. One solution I am aware of is
exec </dev/null >/dev/null 2>/dev/null
in /etc/runit/2 just before runsvdir. What do you think?

Alverstone

Member

Registered: 2024-10-06

Posts: 21  

Re: Excalibur, runit's supervision tree inherits tty1, misbehavior

Another misbehavior here is that tty1 gets cluttered with log messages.

Lorenzo

Member

Registered: 2020-03-03

Posts: 45  

Re: Excalibur, runit's supervision tree inherits tty1, misbehavior

Hi!

<sysrq>+K on tty1 brings the system down

One solution I am aware of is
exec </dev/null >/dev/null 2>/dev/null

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

Alverstone

Member

Registered: 2024-10-06

Posts: 21  

Re: Excalibur, runit's supervision tree inherits tty1, misbehavior

but this discards all output from runsvdir right?

Correct.

Or are you able to get it in some other way?

Yep, I've put /dev/tty12 instead of /dev/null there. <sysrq>+K on tty12 still brings the system down, but I don't care because it doesn't get in the way of my routinely workflow, unlike tty1 which I use heavily. I have some suspicions that part of the output gets lost somehow, though... Need to test that more thoroughly.

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

I hurry to notify you that I (very personally) find runsvdir's cmdline logging feature useless. Ever since I've put an svlogd on every service that needs it, and >/dev/null 2>&1 on every service that maintains logs on its own (hello mullvad-daemon), my ps -ef | grep runsvdir is

runsvdir -P /etc/service log: ...........................................................................................................................................................................................................................................................................................................................................................................................................

and my tty12 console output is as good as non-existent.

Regarding your FIFO approach, I mostly agree with it, but will still give you some input that popped up in my head.

First, in case of a big amount of services, will the default 16 pages be enough to keep all the logs in the FIFO before the svlogd starts? I think it should, but if you settle on this solution, maybe you want to keep your hand on the pulse for possible bug reports. Bottom line, you can start svlogd prior to runsvdir and then restart it under runsv.

Second, consistency. Stage 1 and sysvinit scripts log to tty1. Are runsvdir logs important enough to be concerned about, or is nobody interested in seeing them anyway? sysvinit logs are very important as they notify you about possible errors during startup of critical parts, I presume many people rely on them and I am no exception. On the other hand, I (very personally) do not find runsvdir logs as useful. As long as I get a getty I will be fine. I can imagine a few use cases to it. One would be not using svlogd for getty, this way if getty fails, you immediately know why. Is this useful? No, because since you can't log in you would need a separate boot media anyway, as such you could as well check the log. On the other hand, some critical, not very verbose services, could still make use of it. Want to check errors/warning? Switch to the tty and read the text on your screen. Easy, no hassle, no logging in as root etc etc.

Lastly, why /run/runit/runsvdir-log? This beats the purpose. I suggest this is changed to /var/log/runit instead.

I humbly suggest the following modifications.

SVNAME=runsvdir-log
DEF=/etc/default/runsvdir-log
PIPE=/run/runit/runsvdirpipe
is_number () {
    case "$1" in
        *[!0-9]*|"") return 1;;
        *) return 0;;
    esac
}

if [ -L "$SVDIR/.$SVNAME" ]; then
    mv "$SVDIR/.$SVNAME" "$SVDIR/$SVNAME"
fi

[ -f "$DEF" ] && . "$DEF"

if is_number "$LOG_TTY" && [ -c /dev/tty$LOG_TTY ]; then
    echo "runsvdir log goes to /dev/tty$LOG_TTY"
    PIPE=/dev/tty$LOG_TTY
    [ -L "$SVDIR/$SVNAME" ] && mv "$SVDIR/$SVNAME" "$SVDIR/.$SVNAME"
elif ! [ -L "$SVDIR/$SVNAME" ]; then
    PIPE=/dev/console # default
elif ! mkfifo "$PIPE"; then
    echo "Failed to create runsvdir pipe for logging: $PIPE"
    echo "runsvdir will run with logging disabled"
    PIPE=/dev/null
    [ -L "$SVDIR/$SVNAME" ] && mv "$SVDIR/$SVNAME" "$SVDIR/.$SVNAME"
fi

# no blocking for FIFO, please, so <> is mandatory
exec <> "$PIPE"
# must redirect twice for FIFO
exec env - PATH="$PATH"  runsvdir -P "${SVDIR}" >"$PIPE" 2>"$PIPE"

and

#!/bin/sh

SVNAME="runsvdir-log"
LOG=/var/log/runit/"$SVNAME"
if ! mkdir -p "$LOG"; then
    # mkdir output error already, this is to help making sense of it
    echo "$SVNAME: $LOG: mkdir failed" >&2
    sv d .
fi
chown -R _runit-log:adm "$LOG"
chmod 750 "$LOG"

exec 2>&1
exec < /run/runit/runsvdirpipe

echo "Starting $SVNAME"
exec chpst -u _runit-log svlogd -tt "$LOG"

I find this quite involved to be honest. I am not sure how good exactly the idea is. Also, if svlogd fails here, you'll never know why because of the loop, it might get somebody confused. I honestly fail to see a flawless solution here. I suspect the scripts above are flexible enough to let people do whatever they want. Put LOG_TTY=1 in the /etc/default/runsvdir-log and you get the default behavior.

Also, maybe somehow add an option to the runsvdir-log service to duplicate the log to a tty. I'm afraid my head is not clear enough now to suggest anything more sensible.

Also, the scripts above work, I've just tested them.

Alverstone

Member

Registered: 2024-10-06

Posts: 21  

Re: Excalibur, runit's supervision tree inherits tty1, misbehavior

Also, here

elif ! mkfifo "$PIPE"; then

maybe use /dev/console instead of /dev/null, it would be more sensible.

Last edited by Alverstone (Today 15:40:27)