You are not logged in.
Sound very much like a network issue I recently had. Maybe try 6.1.0-16, that fixed it for me.
Just FYI: With 6.1.0-16, it works again.
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 :-)
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
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.
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!
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!
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 …
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?!
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?!
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!
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"?!
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 …
$ 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 …
/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.
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 …
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!
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 …
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 :-(
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 … :-(
Are we ready for a group hug?
Yeah, of course ;-)
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 ;-)
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!
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?!