The officially official Devuan Forum!

You are not logged in.

#4 Hardware & System Configuration » Kernel 6.1.0-15 causes network-manager to hang when shutting down » 2023-12-14 11:10:17

l3u
Replies: 7

Hi all :-)

I have Devuan on a quite old notebook (still x86, but I don't know if that matters). I updated it yesterday and noticed it would not shut down correctly anymore, just hangs and nothing happens.

I played around a bit and found that network-manager would refuse to stop, and later on, "Deconfigurating network interfaces" (or such) would finally block the shutdown, so that one can only push the power button so long the machine is finally killed.

This only happens using kernel 6.1.0-15. When booting 6.1.0-13, the machine shuts down normally.

I'm quite new to Devuan (and to the whole Debian world, I'm normally on Gentoo or Artix), so: Where would I report such an issue or search for anybody else having done so? And what's the proper way to tell my system it should boot 6.1.0-13 for now, and keep the kernel? On Gentoo, we normally build a kernel ourselves, and the package manager would only touch the sources when cleaning up, not the compiled kernel.

Thanks for all (newbie) help :-)

#5 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-14 08:15:16

l3u

Here we are! Simply switching the monitor off (physically) spawns an lxqt-config-monitor zombie process:

$ ps -ef | grep lxqt-config-monitor
serverh+ 26115  3339  0 09:12 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 26121 26106  0 09:12 pts/1    00:00:00 grep lxqt-config-monitor

And here's who does it:

$ ps -fp 3339
UID        PID  PPID  C STIME TTY          TIME CMD
serverh+  3339  3333  0 Nov22 ?        00:25:52 lxqt-session

#6 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-13 18:28:07

l3u

One of the maintainers guessworks that this could be caused by some broken Debian Bookworm package: https://github.com/lxqt/lxqt/discussion … nt-7844956

Still, I have no idea how to debug this … I'll check for the parent as soon as I see the next lost process.

#7 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-13 13:47:15

l3u

Searching for some answer, I also posted this on the LxQt "forum": https://github.com/lxqt/lxqt/discussions/2489

Apparently, this is a Debian issue, as one user answering pointed me to this here: https://github.com/lxqt/lxqt/discussions/2489
which looks exactly like the problem I'm seeing.

I use the machine only to host a QEMU virtual machine which provides the actual server, so I never ran into that "Maximum number of clients reached" problem, because it doesn't affect already opened windows and I normally don't open new ones.

Well, maybe, swapping monitor hardware may fix it as the poster of the mentioned issue states … but anyway, this should not happen! Where would I report this? I think this definitely has to be fixed upstream!

#8 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-13 11:17:18

l3u

Even if I turn off my monitor manually, I get one "/usr/bin/lxqt-config-monitor -l" zombie process!!!

Is there a way to find out what trigger this?! There must be some daemon running this command!

#9 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-13 07:34:51

l3u

Okay, just tried it.

It doesn't matter if the energy management turns off the monitor, or if xscreensaver does it. In both cases, the zombie processes appear.

I now tried to work around it by moving lxqt-config-monitor to lxqt-config-monitor~ and adding a fake script named lxqt-config-monitor that does nothing but logging that something wanted to run lxqt-config-monitor.

Interestingly, this also doesn't fix the problem: Now, the script becomes the zombie process. So apparently, lxqt-config-monitor itself isn't even the problem!

On my other machine I played around with yesterday evening, lxqt-config-monitor wasn't even started when the monitor was turned off. So why does this even happen, and what is starting lxqt-config-monitor?! Seems like the problem is there …

#10 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-12 20:39:16

l3u

I'm pretty sure that producing hundreds of zombie processes spamming a logfile with hundreds of megabytes in error messages would not be considered expected behavior ;-)

I won't have physical access to the machine in question until tomorrow, so I played around with another one also running LxQt.

There, the monitor can be turned off both using the energy management and xscreensaver. In neither case, such zombie processes appear.

What is a bit odd is that lxqt-config-monitor isn't even started … I wrote a small wrapper script that writes "lxqt-config-monitor started" to syslog and then actually starts it … neither when the monitor goes off, nor when it goes on again, lxqt-config-monitor is run.

So … what does even start it on the other machine?!

#11 Re: Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-12 17:17:05

l3u

Okay, I just saw that xscreensaver also seems to have the ability to turn off the monitor. I'll try to enable this and to disable the energy management … however, this is definitely not expected behavior, is it?!

#12 Desktop and Multimedia » Dozens of lxqt-config-monitor processes are started » 2023-12-12 16:28:40

l3u
Replies: 14

Hi all :-)

I have LxQt running.

As soon as the energy management turns off the monitor, a lot of "lxqt-config-monitor -l" processes are started. Maybe, the process keeps crashing and is started over and over again. At the time I saw it, the system was up several weeks, and I had > 200 such processes:

 $ ps -ef | grep lxqt-config-monitor
...
serverh+ 19102  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19112  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19122  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19132  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19143  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19153  3339  0 16:30 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19163  3339  0 16:31 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19173  3339  0 16:31 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19183  3339  0 16:31 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
serverh+ 19193  3339  0 16:31 ?        00:00:00 /usr/bin/lxqt-config-monitor -l
...

Playing around a bit, I saw that at the exact moment the energy management turns off the monitor, a few such processes appear.

I also played around with the xscreensaver settings. This seems to change nothing. Also, I never changed any screen setting. Running "lxqt-config-monitor -l" manually doesn't crash and returns normally.

As soon as the monitor is turned off, the following appears over and over again in ~/.xsession-errors (it was > 300 MB big at the time I noticed this):

lxqt-session: "Session 'session': display device '/dev/dri/card0'"
[load.applyBestSettings()] Finished
qt.qpa.xcb: QXcbConnection: XCB error: 148 (Unknown), sequence: 190, resource id: 0, major code: 140 (Unknown), minor code: 20
lxqt-session: "Session 'session': display device '/dev/dri/card0'"
[load.applyBestSettings()] Finished
lxqt-config-monitor: Applying current settings...
Output:  "DP-1"
Output:  "HDMI-1"
Output:  "DP-2"
Output:  "HDMI-2"
lxqt-config-monitor: Settings applied.

What may cause this? And how can I prevent it other than turning off the energy management?

Thanks for all help!

#13 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-26 23:29:41

l3u

Question is if this is something one (Debian) could or wanted to "fix", if the problem only arises because of a different implementation being used. Maybe they say "We use 'our' start-stop-daemon, we don't care about what those OpenRC guys do"?!

#14 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-12 22:55:29

l3u

This is only possibly a bug … the core problem is that Devuan (and most probably Debian) uses another start-stop-daemon implementation than Gentoo does use (it's not the OpenRC version after all). On Gentoo, there's no problem. Everything works as expected. But Devuan's (perhaps Debian's) start-stop-daemon apparently chokes on --exec if an interpreter (in this case python3) is used.

I'm not sure if the Debian guys would be very interested in me filing a bug about the (non-Systemd) start-stop-daemon should be the one from another Distribution that provides the init system not being used upstream …

#15 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-04 22:09:01

l3u
$ which python3
/usr/bin/python3

The daemon does start without a problem. Nevertheless, the Devuan version of start-stop-daemon still doesn't works as expected …

At least, I found a workaround.

I'm pretty sure this is due to Devuan allowing OpenRC to be installed, but not really integrating it deeply, or really relying on OpenRC. Like e. g. Artix does …

#16 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-04 05:49:50

l3u

/usr/bin/python actually didn't exist, I didn't know about the python-is-python3 package yet; I'm quite new to Devuan and also never used Debian before (you guys still handle both Python 2 and 3 after all these years?! ;-).

But that did not cause it. The shebang of my daemon starter is

#!/usr/bin/env python3

and this one exists.

Also, creating the missing "python" symlink also did, as expected, not fix the problem.

A (retired) Gentoo Dev on the Gentoo Forums said:

The fundamental difference here is that Gentoo uses /sbin/start-stop-daemon from OpenRC while Devuan relies on the version in dpkg.
They are meant to be compatible, but something looks a bit different when processing arguments.

The biggest difference to the default stop() in /lib/rc/sh/start-stop-daemon.sh and your example is the passing of "--exec ${command}" in the former.
This is looking as it is processing the stop differently on Devuan because of this. Particularly if "/proc/${pid}/exe" != "${command}"

Workarounds include defining a stop() in your script or else adding supervisor="supervise-daemon" which will use the same tool in all distros.

#17 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-03 18:44:47

l3u

Apparently, Devuan uses another start-stop-daemon as Gentoo does.

The code to be executed generated by OpenRC evaluates to

start-stop-daemon --stop --exec /usr/bin/go-e-pvsd --pidfile /run/go-e-pvsd.pid

and Devuan's start-stop-daemon seems to choke on the "--exec" argument.

So a workaround for Devuan would be to change

command="/usr/bin/go-e-pvsd"

to

command="/usr/bin/python3 /usr/bin/go-e-pvsd"

This makes it work. Still a bit weird …

#18 Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-09-30 08:23:13

l3u
Replies: 15

Hi all :-)

I wrote a Python daemon to control PV surplus charging with an go-e Charger (cf. https://gitlab.com/l3u/go-e-pvsd if this may be of interest for anybody). The daemon is well-behaved, backgrounds itself and creates a pidfile.

I also wrote a quite simple OpenRC init script to start it:

#!/sbin/openrc-run

depend() {
    need net
    use logger
}

command="/usr/bin/go-e-pvsd"
pidfile="/run/${RC_SVCNAME}.pid"
command_args="-s"
command_args_background="-d -p $pidfile"

Both on my Gentoo/OpenRC machine and my Artix/OpenRC machine, the script does what it should, starts and stops the daemon:

# ./go-e-pvsd start
 * Starting go-e-pvsd ...                                                [ ok ]
# ./go-e-pvsd stop
 * Stopping go-e-pvsd ...                                                [ ok ]
#

But if I use it on the Devuan server (where it should run later), I can start the daemon, but not stop it:

# ./go-e-pvsd start
 * Starting go-e-pvsd ...                                                [ ok ]
# ./go-e-pvsd stop
 * Stopping go-e-pvsd ...
No /usr/bin/go-e-pvsd found running; none killed.
 * Failed to stop go-e-pvsd                                              [ !! ]
 * ERROR: go-e-pvsd failed to stop
#

However, the pidfile is created as it should be:

cat /run/go-e-pvsd.pid 
21411

the daemon runs and actually does have this pid:

# ps -ef | grep /usr/bin/go-e-pvsd
root     21411     1  1 09:47 ?        00:00:00 python3 /usr/bin/go-e-pvsd -d -p /run/go-e-pvsd.pid -vs
root     21454 21389  0 09:48 pts/0    00:00:00 grep --color=auto /usr/bin/go-e-pvsd

and I can also manually tell it to stop by sending a SIGTERM:

# kill -s SIGTERM 21411
# ps -ef | grep /usr/bin/go-e-pvsd
root   21980 21976  0 10:21 pts/0    00:00:00 grep /usr/bin/go-e-pvsd

Starting and stopping the daemon using a sysvinit init script like this works as expected:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          go-e-pvsd
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start the go-e PV surplus daemon
# Description:       Daemon for PV surplus charging
#                    with an go-e Charger
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/go-e-pvsd
NAME=go-e-pvsd
DESC="pv surplus charging daemon"
PIDFILE=/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

DAEMON_OPTS="-d -p $PIDFILE -s"

test -x $DAEMON || exit 0

set -e

. /lib/lsb/init-functions

case "$1" in
    start)
        status="0"
        pidofproc -p $PIDFILE $DAEMON >/dev/null || status="$?"
        if [ "$status" = 0 ]; then
            log_daemon_msg "$NAME is already running" $NAME
            log_end_msg 0
            exit 0
        fi
        log_daemon_msg "Starting $DESC" $NAME
        if ! start-stop-daemon --start --pidfile $PIDFILE \
                 --exec $DAEMON -- $DAEMON_OPTS
        then
            log_end_msg 1
        else
            log_end_msg 0
        fi
        ;;
    stop)
        log_daemon_msg "Stopping $DESC" $NAME
        if start-stop-daemon --stop --pidfile $PIDFILE
        then
            rm -f $PIDFILE
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;
    restart)
        $0 stop
        $0 start
        ;;
    status)
        status_of_proc -p "$PIDFILE" "$DAEMON" go-e-pvsd && exit 0 || exit $?
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|status}" >&2
        exit 1
        ;;
esac

exit 0

So … what's wrong with OpenRC? Why can't it stop the daemon, although both the process name and the pidfile provide the correct information?

Thanks for all help!

#19 Re: Installation » [SOLVED] Brother's BrGenML1 driver doesn't work » 2022-12-30 12:48:27

l3u

Yay, I could get it to work :-) The printer driver is 32 bit. So I had to install libc6-i386, and the Gentoo/Artix ported package worked!

The CUPS error log is a bit confusing. Nowhere a hint that the missing 32 bit stuff was causing this …

#20 Re: Installation » [SOLVED] Brother's BrGenML1 driver doesn't work » 2022-12-30 12:11:49

l3u
l3u wrote:

I also tried to use Brother's upstream brgenml1lpr and brgenml1cupswrapper packages (the Gentoo package is based on), with the same result.

Those ARE the linked .deb packages :-(

#21 Re: Installation » [SOLVED] Brother's BrGenML1 driver doesn't work » 2022-12-30 09:40:59

l3u

Does nobody use this or have an idea about this? This actually currently stops me from stopping playing around with Devuan in a virtual machine and really doing the migration … :-(

#22 Re: Installation » [SOLVED] Starting Samba fails using OpenRC » 2022-12-28 16:43:35

l3u
golinux wrote:

Are we ready for a group hug?

Yeah, of course ;-)

#23 Re: Installation » [SOLVED] Starting Samba fails using OpenRC » 2022-12-27 11:49:07

l3u

Well, tbh, I don't really consider myself a n00b after having used Gentoo for quite exactly 18 years now ;-)

That behavior was just plain unexpected (to me as a Devuan newbie). And as it was (from my point of view) a similar problem like the Radicale init script one, I simply supposed the init script to be the problem, not Debian's way how su works. Esp. as Devuan doesn't "really" support OpenRC, because it only lets OpenRC execute the Sysvinit init scripts. And states that OpenRC support would be "experimental".

Of course there's no excuse for the "crime" (as you call it) not to have searched the board for a su problem when Samba won't start, but – and I again beg your pardon – this interconnection was in no way clear to me, esp. facing the fact that I can start other init script with a plain "su" (not "su -") session, beacuse they do include a PATH statement containing "/sbin". May other newbies with this very problem find this thread to avoid such posts in the future.

But I think this issue is now solved, and I learned that Debian's su works in an odd way (if I'm very bored some time, I'll read through the lengthy disussion you linked to find out why Debian acts in another way as other distributions do here. But for now, I simply accept it as a given fact).

So everything is good concerning this … at least for me ;-)

#24 Installation » [SOLVED] Brother's BrGenML1 driver doesn't work » 2022-12-27 08:49:12

l3u
Replies: 5

Hi all :-)

I'm migrating a Gentoo machine to Devuan.

How can I use Brother's BrGenML1 printer driver?

I first tried to manually install it by creating a deb package from Gentoo's slightly patched BrGenML1 package. This one works without a problem on Gentoo, and I also ported the very same package to Artix Linux where I also can use it without a problem.

On Devuan, this one sadly does not work. After having added the printer the same way I did on Gentoo and Artix, I can't print: Nothing happens, and the CUPS error log says:

W [27/Dec/2022:09:02:17 +0100] [Job 8] Grayscale/monochrome printing requested for this job but Poppler is not able to convert to grayscale/monochrome PostScript.
W [27/Dec/2022:09:02:17 +0100] [Job 8] Use \"pdftops-renderer\" option (see cups-filters README file) to use Ghostscript or MuPDF for the PDF -> PostScript conversion.

The second line always appears when e.g. printing the CUPS test page. I googled for the first line's error message and hit some Debian bug report, but I can't really figure out what's wrong here.

I also tried to use Brother's upstream brgenml1lpr and brgenml1cupswrapper packages (the Gentoo package is based on), with the same result.

Does anybody use BrGenML1 who can help me?

Thanks in advance for all help!

#25 Re: Installation » [SOLVED] Starting Samba fails using OpenRC » 2022-12-27 07:56:01

l3u

Well, that of course explains it. I would never have thought that this could be the cause though …

Thanks for the information! No hard feelings ;-)

I now simply shipped around this (imo odd) behavior by simply creating a file in /etc/profile.d/ (/etc/profile.d/path.sh) with the following content:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Just that I maybe understand this a bit better: What's the point in leaving /sbin out of the PATH? And what's the point of only getting root's PATH when using su - instead of su?!

Board footer

Forum Software