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

Hi,

[ sorry I don't have the solution, just some things to check ]

are you using the runit-services package, or you have your own set of runscripts or none of the two? is lightdm a runit service or is run as sysvinit script by the sysv emulation at startup?

if you have lightdm as runit service the right command is

sv stop/start lightdm

or (for a full restart)

sv e lightdm

just to be sure, Debian + systemd?

Anyway, my suggestion is to try to replace some xfce component with some other program and see if it works:

It may be the screensaver/locker that doesn't work, for example it freezes while it should draw the window for user/passwd to unlock the screen: what are you using as screensaver/locker?
I'm using xscreensaver and it works fine with elogind (despite launching a xscreensaver-systemd), but I'm using Debian+ lxqt + runit and I'm not sure if it's lxqt-powermanagment that does the magic

another thing is to try to stop completely/kill the xfce4-power-manager daemon before closing the lid and see if elogind can handle the job;  try with elogind + xscreensaver, not sure if xfce-screensaver will work without the xfce4-power-manager

Lorenzo

OT: by any chance are you the same Danielsan of the "Debianizzati" italian forum?

Hi,

happy to be wrong about this, but as far as I know there is no s6-init package in Devuan.. you can install the s6 package, but all the init integration is not provided, so you have to serve yourself.

That page says " either available or being considered for inclusion "; I think only runit and openrc are provided as alternative init *for now*

Lorenzo

Hi,

scripts for avahi-daemon and avahi-dnsconfd have been added
to the latest orphan-sysvinit-scripts version (0.13)

Lorenzo