OpenRC init script works fine on Gentoo and Artix – but not on Devuan

l3u · 2023-09-30 08:23:13

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!

l3u · 2023-10-03 18:44:47

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 …

ralph.ronnquist · 2023-10-03 21:48:07

It might be that the script has "/usr/bin/python" as interpreter, which might not exist on your Devuan system.

alexkemp · 2023-10-03 22:31:25

Only if your python installation is broken, or non-existent of course (see the link for /usr/bin/python, etc. below):

$ la /usr/bin/python*
lrwxrwxrwx 1 root root       7 Jan  8  2023 /usr/bin/python -> python3
lrwxrwxrwx 1 root root      10 Apr  9 11:22 /usr/bin/python3 -> python3.11
-rwxr-xr-x 1 root root 6831704 Mar 13  2023 /usr/bin/python3.11
lrwxrwxrwx 1 root root      34 Mar 13  2023 /usr/bin/python3.11-config -> x86_64-linux-gnu-python3.11-config
-rwxr-xr-x 2 root root 4755312 Jul  9  2020 /usr/bin/python3.5
-rwxr-xr-x 2 root root 4755312 Jul  9  2020 /usr/bin/python3.5m
lrwxrwxrwx 1 root root      17 Apr  9 11:22 /usr/bin/python3-config -> python3.11-config
$ neofetch
   ..,,;;;::;,..                   alexk@ng3 
           `':ddd;:,.              --------- 
                 `'dPPd:,.         OS: Devuan GNU/Linux 5 (daedalus) x86_64 
                     `:b$$b`.      Model: 90BJ008CUK Lenovo H30-05 
                        'P$$$d`    Kernel: 6.1.0-13-amd64 
                         .$$$$$`   Uptime: 1 day, 9 hours, 8 mins 
                         ;$$$$$P   Packages: 3062 (dpkg) 
                      .:P$$$$$$`   Shell: bash 5.2.15 
                  .,:b$$$$$$$;'    Resolution: 1366x768 
             .,:dP$$$$$$$$b:'      DE: Xfce 4.18 
      .,:;db$$$$$$$$$$Pd'`         WM: Xfwm4 
 ,db$$$$$$$$$$$$$$b:'`             WM Theme: Default 
:$$$$$$$$$$$$b:'`                  Theme: Clearlooks-Phenix-Sapphire [GTK2] 
 `$$$$$bd:''`                      Icons: oxygen [GTK2] 
   `'''`                           Terminal: xfce4-terminal 
                                   Terminal Font: Monospace 12 
                                   CPU: AMD A8-7410 APU with AMD Radeon R5 Graphics (4) @ 2.200GHz 
                                   GPU: AMD ATI Radeon R4/R5 Graphics 
                                   Memory: 2150MiB / 7356MiB

Last edited by alexkemp (2023-10-03 22:34:53)

ralph.ronnquist · 2023-10-03 23:25:36

Afaict there are two packages competing about the /usr/bin/python pathname, namely packages python-is-python2 and python-is-python3.

I think the upshot for this was that python3 changed a lot in syntax as well as in data representations from python2 and at that time it was considered wrong to use the plain "python" in their she-bang. In support of that the python installations stopped committing to that version choice and instead offered the choice as different packages.

Apparently some desktop environment(s) might want to make that choice for us, but technically it remains a user choice in Devuan daedalus.

l3u · 2023-10-04 05:49:50

/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.

Last edited by l3u (2023-10-04 05:50:14)

chris2be8 · 2023-10-04 16:21:40

Read the man page for env.

#!/usr/bin/env python3

Will only work if python3 is in it's $PATH. Try which python3 to make sure it's installed on your system.

l3u · 2023-10-04 22:09:01

$ 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 …

Last edited by l3u (2023-10-04 22:14:13)

ralph.ronnquist · 2023-10-04 23:08:00

It might be worth to clarify here that "Devuan" is not an organisation that wants you to run particular software.

Devuan's contribution to the Linux world is to provide a package repository that includes all Debian packages as is, expect for those needing forking to avoid the ~~systemd~~ infestation.

If you find a bug in the openrc packages (which are not forked) you may report that to the Debian bugtracker.

Though your issue might rather be in the combination of packages you have installed and you are right to raise it here as this Devuan community may well include people who also use openrc packages.

l3u · 2023-10-12 22:55:29

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 …

boughtonp · 2023-10-19 14:04:56

Any package you find in the Debian Stable repositories is supported by Debian - it doesn't matter if it is installed by default.

Since OpenRC is available for Debian Stable and is not modified by Devuan, issues with it should be raised with Debian at //bugs.debian.org/openrc

//packages.debian.org/bookworm/openrc
//pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=openrc=0.45.2-2

Altoid · 2023-10-19 15:39:26

Hello:

boughtonp wrote:

Any package you find in the Debian Stable repositories is supported by Debian - it doesn't matter if it is installed by default.

I would not be too sure about that.
ie: the "supported" and "it doesn't matter if it is installed by default" parts.

Some time ago there was a thread related to timeshift with a LUKS / btrfs combination and how it worked properly in Debian and not in Devuan.

After a long exchange of ideas here at Dev1, a bug was reported to Debian by the OP.

Quite obviously, Devuan was not mentioned.

The bug was reported to because timeshift (with the LUKS / btrfs combination) worked perfectly well with Debian+systemd but not with Debian+sysvinit.

If interested, see bug #1034328

The answer from Debian?

Boyuan Yang @bugs.debian.org wrote:

Since sysvinit is not enabled by default in Debian, I do not consider this
bug as release-critical. Downgrading the bug severity to "normal".

Best,

A.

Last edited by Altoid (2023-10-19 15:40:00)

boughtonp · 2023-10-19 19:40:00

The situation in that example is not the same as the situation here. Boyuan didn't request it be reported upstream because they were not interested in having the bug fixed, but only because they lacked the ability to diagnose the issue themself.

And since "downgrading to normal" is not "closing as wontfix" that example is not counter to the assertion, (even if it lacked suitable emphasis). There may well be other examples that are (such as when a package is orphaned), but the point is: software in the main Debian repository is, by its presence in that repo, supported by Debian.

Software which instead comes from the Devuan repos - because it has been modified by Devuan - is not supported by Debian, and should first be reported to Devuan (via bugs.devuan.org) not to Debian. (If necessary, the Devuan team can refer it to the Debian maintainer of the unmodified package.)

In this example, given the issue appears to be with OpenRC, we know (by virtue of it being an independent init system) that there is no dependency on systemd, and thus it wont need a Devuan-specific package, and so the place to report it is to Debian's OpenRC maintainers, via bugs.debian.org/openrc

Altoid · 2023-10-19 20:41:47

Hello:

boughtonp wrote:

... situation in that example is not the same as the situation here.

Indeed ...
It did not cross my mind.
I'm sorry if I explained myself incorrectly.

My comment was related exclusively to your asserting that Debian supports all packages in its repositories, installed by default or not.

My view of what transpired in the case I referenced is what I can understand from the maintainer's text within the context of the problem exposed.

ie:
Worked as expected with systemd but did not work with sysvinit.
The main difference, exhaustively documented, being the init software used.

Was there another gremlin at work there?
We don't/won't know.

The maintainer refused to have a look on the grounds of Debian+sysvinit not being a default configuration, his calification of the bug is of no import.

... sysvinit is not enabled by default in Debian ...
... do not consider this bug as release-critical.

Given what the Debian devs/maintainers are doing with the init scripts lately ...
Can anyone be at all surprised?

Thanks for your input.

Best,

A.

Last edited by Altoid (2023-10-19 20:48:19)

boughtonp · 2023-10-19 21:49:05

Altoid wrote:

My comment was related exclusively to your asserting that Debian supports all packages in its repositories, installed by default or not.

You are misinterpreting what I wrote. I attempted to clarify, there was no emphasis on "all" (which does not even exist in what I wrote), but should have been emphasis on "by Debian" - with an implied "not Devuan", because Devuan only support the packages that they have created or modified - i.e. packages which do not exist in the Debian repositories, because they are only in the Devuan repositories.

To repeat: I mistakenly didn't put suitable emphasis on "by Debian". What I apparently should have written there is:

Any package you find in the Debian Stable repositories is supported by Debian - where "supported by Debian" means it belongs in Debian's bug tracker not in Devuan's bug tracker - it doesn't matter if it is installed by default what matters is whether it was modified by Devuan or not; that is the factor which decides which bug tracker it goes in.

How individual Debian maintainers may or not handle reports where the presence/absence of systemd affects an issue does not change this and is not relevant to the point I was making, which was about where to report issues.

-

To hopefully un-derail the thread, I'll note that I wrote what I did to reassert the point that ralph made, in response to the subsequent uncertainty of l3u:

l3u wrote:

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 …

Bugs in a package should be reported to those who maintain that package.

Devuan users are more likely to use OpenRC, discussing OpenRC issues is on-topic here, but Devuan does not maintain the OpenRC package, so for bugs to be fixed they need to be reported to those that do maintain it.

l3u · 2023-10-26 23:29:41

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"?!

The officially official Devuan Forum!

#1 2023-09-30 08:23:13

OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#2 2023-10-03 18:44:47

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#3 2023-10-03 21:48:07

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#4 2023-10-03 22:31:25

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#5 2023-10-03 23:25:36

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#6 2023-10-04 05:49:50

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#7 2023-10-04 16:21:40

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#8 2023-10-04 22:09:01

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#9 2023-10-04 23:08:00

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#10 2023-10-12 22:55:29

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#11 2023-10-19 14:04:56

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#12 2023-10-19 15:39:26

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#13 2023-10-19 19:40:00

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#14 2023-10-19 20:41:47

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#15 2023-10-19 21:49:05

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

#16 2023-10-26 23:29:41

Re: OpenRC init script works fine on Gentoo and Artix – but not on Devuan

Board footer