Posts by abower

abower · Hardware & System Configuration

Thanks for the logging tips, Alverstone! I haven't had cause to use yet but useful to have in mind.

I think you are probably right about the serial port. Unexpected use of the serial port is a classic cause of unexplained problems, like debug being interleaved into operational communications and slow/blocked processing!

Perhaps some other test should be used as a proxy to determine whether the serial port is suitable, e.g. a kernel command line value or the enablement of serial logging from some other component.

abower · Hardware & System Configuration

Hi guys, I spotted the pending change at https://salsa.debian.org/debian/runit/- … b633b819d5 which directed me to the discussion here.

I understand the changes fix a serious problem but do we now have no way of discovering failures on a headless system?

readproctitle was far from ideal but at least it was _possible_ to diagnose issues after the fact. Really we need a proper log as a fallback/catch-all for services that don't have their own logger because they don't have any output or whose logger script is itself faulty. I'm not sure if you covered this in the above discussion, my apologies for not following it all!

Thanks!

abower · Documentation

Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.

Thanks for the idea, steve_v! I just set up a runit-based solution. It seems yours has a more sophisticated lifecycle integration with the session/login manager (I'm not so clued up on that stuff) but here's what I have done anyhow:

The runit scripts may be found at runit-desktop - they can be unpacked to ~/.xusersvc. Here's a sample:

#!/usr/bin/sh

SVDIR=$(dirname ${PWD}) sv start pipewire || exit 1

set -e
exec 2>&1
echo "Starting ${PWD##*/}..."

exec /usr/bin/pipewire-pulse

Then I have an XFCE Application autostart entry (cat "~/.config/autostart/User runsvdir.desktop":

[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=User runsvdir
Comment=Start user runit services
Exec=runsvdir .xusersvc
OnlyShowIn=XFCE;
RunHook=0
StartupNotify=false
Terminal=false
Hidden=false

and we are away (sv status .xusersvc/*)!

run: .xusersvc/pipewire: (pid 19758) 1035s; run: log: (pid 19757) 1035s
run: .xusersvc/pipewire-pulse: (pid 19778) 1035s; run: log: (pid 19769) 1035s
run: .xusersvc/wireplumber: (pid 19771) 1035s; run: log: (pid 19768) 1035s

With log files sitting in ~/.xuserlog/*/current:

024-04-19_22:58:50.32626 ok: run: pipewire: (pid 19758) 0s
2024-04-19_22:58:50.32632 Starting pipewire-pulse...
2024-04-19_22:58:51.58468 [W][06850.910390] default      | [   snap-policy.c:   71 pw_snap_get_audio_permissions()] snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap audio permissions won't be honored.

Supervision seems to end satisfactorily on session exit although I did also try a logout hook that ran pkill -HUP on the user's runsvdir but I'm not sure what it gained.

Fortunately it seems the services create their own sockets when systemd activation is absent and we don't need to worry about the various .socket units.

(Also, my first post although I have used the OS for some years - thank you Devuan people!)

The officially official Devuan Forum!

#1 Re: Hardware & System Configuration » Excalibur, runit's supervision tree inherits tty1, misbehavior » 2024-11-17 22:00:30

#2 Re: Hardware & System Configuration » Excalibur, runit's supervision tree inherits tty1, misbehavior » 2024-11-09 16:49:15

#3 Re: Documentation » How to: Devuan 5 Daedalus an pipewire » 2024-04-19 23:38:39

Board footer