SOLVED: Devuan's "systemctl daemon-reload"

nobodyuknow · 2021-01-08 19:05:27

The latest version of Expressvpn is having problems. Expressvpn support staff told me to execute "systemctl daemon-reload" but systemctl is a systemd thing. What's the Devuan equivalent? I selected SysV for init software in Beowulf Cinnamon.

On a related subject, there is a directory "/etc/systemd" but is that actually in use or is it a holdover from Debian?

Last edited by nobodyuknow (2021-01-16 19:42:51)

Head_on_a_Stick · 2021-01-08 19:15:27

nobodyuknow wrote:

What's the Devuan equivalent?

There is no equivalent for sysvinit because that doesn't have a dependency tree to rebuild or any socket management to reset. It's fine to just restart the init service though:

# /etc/init.d/$service restart

Replace $service with the actual name of the service.

What is the actual problem that the support staff are trying to solve? There might be a sysvinit-specific solution for it.

nobodyuknow wrote:

there is a directory "/etc/systemd" but is that actually in use or is it an artifact from Debian?

That directory is for enabling & masking unit files and also for local units and the systemd configuration files so I don't think it's used at all in Devuan.

GlennW · 2021-01-08 22:20:55

I use open-rc and I am able to control services with "service $service start|stop|restart|status".

Not all services are the same, ymmv.

rc-update and rc-service come in handy too.

nobodyuknow · 2021-01-08 22:26:13

Thanks for the replies.

I'll keep that restart command for future use. I might have to build an openrc system to play with it.

What happened was, ExpressVPN released a new .deb (expressvpn_3.4.0.62-1_amd64.deb), which resulted in the following error when I tried to connect:

expressvpn connect <city>
Cannot connect to expressvpnd daemon.
It seems that the expressvpn daemon is not running.
Please run "sudo service expressvpn restart" to start it.
If the problem persists, please contact us.

sudo service expressvpn restart
[FAIL] Restarting ExpressVPN service: expressvpnd failed!

Only after I executed "dpkg --purge expressvpn" and dpkg -i expressvpn_3.3.0.21-1_amd64.deb" (the previous .deb) and "expressvpn activate" was I able to get ExpressVPN to run again. ExpressVPN admitted they do not test against any Debian spin that uses an init other than systemd. I suspect ExpressVPN only tests using Debian and Ubuntu (or a spin like Linux Mint).

I can use ExpressVPN with the older .deb, but eventually that will stop working. By the way, the new .deb works on Linux Mint and Sparky Linux, both of which employ the dreaded systemd.

Last edited by nobodyuknow (2021-01-08 22:35:13)

Head_on_a_Stick · 2021-01-08 22:50:18

GlennW wrote:

I use open-rc and I am able to control services with "service $service start|stop|restart|status".

That also works under sysvinit, I only used a direct call to the service script because it was slightly less ambiguous than posting

# service $service restart

nobodyuknow wrote:

ExpressVPN released a new .deb (expressvpn_3.4.0.62-1_amd64.deb), which resulted in the following error when I tried to connect

Can you share the content of /etc/init.d/expressvpn for the new version?

If you don't want to install it again then you can extract the file with

ar x expressvpn_3.4.0.62-1_amd64.deb
tar xf data.tar*
cat etc/init.d/expressvpn

Note the lack of a leading forward slash for the path on the last command — etc/init.d/ is relative to the current working directory, the full path should not be used.

zapper · 2021-01-09 01:45:12

Actually, there might be one alternative to making expressvpn work, if you want...

the init known as s6 or s6-init might be able to get it running. Supposedly, it has some of the same functions as system dumb, only way more lightweight.

It is still somewhat bloated, but its worth a try right?

nobodyuknow · 2021-01-09 18:04:49

@Head_on_a_Stick

You lost me on the third command:

nobody@toshiba128:~$ ar x Downloads/expressvpn_3.4.0.62-1_amd64.deb
nobody@toshiba128:~$ tar xf data.tar*
nobody@toshiba128:~$ cat etc/init.d/expressvpn
cat: etc/init.d/expressvpn: No such file or directory
nobody@toshiba128:~$ ls
control.tar.gz	Desktop    etc		Pictures   usde
data.tar.gz	Documents  _gpgbuilder	Public	   usr
debian-binary	Downloads  Music	Templates  Videos
nobody@toshiba128:~$

So what the heck, I purged the working .deb and installed the funky one:

nobody@toshiba128:~$ cat  /etc/init.d/expressvpn
#! /usr/bin/env bash

### BEGIN INIT INFO
# Provides:          expressvpn
# Required-Start:    $remote_fs $network
# Required-Stop:     $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start expressvpn at boot time
### END INIT INFO

# Do NOT "set -e"

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="ExpressVPN service"
NAME=expressvpnd
DAEMON=/usr/sbin/$NAME
DAEMON_ARGS="--client-version 3.4.0 --client-build 62"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/expressvpn

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 5

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

STDOUT=${STDOUT:-"/dev/null"}
STDERR=${STDERR:-"/dev/null"}

# Load the VERBOSE setting and other rcS variables
[ -f /lib/init/vars.sh ] && . /lib/init/vars.sh

# To be replaced by LSB functions.
function log_daemon_msg() {
    echo -n "$@"
}

# To be replaced by LSB functions.
function log_end_msg() {
    retval=$1
    if [ "$retval" -eq 0 ]; then
        echo " [ OK ]"
    else
        echo " [ FAILED ]"
    fi
    return "$retval"
}

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
[ -f /lib/lsb/init-functions ] && . /lib/lsb/init-functions

function pidofproc() {
    if [ $# -ne 3 ]; then
        echo "Expected three arguments, e.g. $0 -p pidfile daemon-name"
    fi

    local PID PIDFILE
    PID=$(pgrep -f "$3")
    PIDFILE=$(cat "$2")

    if [ "x$PIDFILE" == "x" ]; then
        return 1
    fi

    if [ "x$PID" != "x" ] && [ "$PIDFILE" == "$PID" ]; then
        return 0
    fi

    return 1
}

function killproc() {
    if [ $# -ne 3 ]; then
        echo "Expected three arguments, e.g. $0 -p pidfile signal"
    fi

    local PID
    PID=$(cat "$2")

    /bin/kill -s "$3" "$PID"
    while true; do
        if pidof "$(basename "$DAEMON")" >/dev/null; then
            return 0
        fi

        sleep 1
        n=$(( "$n" + 1 ))
        if [ "$n" -eq 30 ]; then
            /bin/kill -s SIGKILL "$PID"
            return 0
        fi
    done
}

#
# Function that starts the daemon/service
#
do_start()
{
    # Return
    #   0 if daemon has been started
    #   1 if daemon was already running
    #   2 if daemon could not be started
    if command -v start-stop-daemon > /dev/null 2>&1; then
        nohup start-stop-daemon --start --quiet -m --pidfile "$PIDFILE" --exec "$DAEMON" -- "$DAEMON_ARGS" >>"$STDOUT" 2>>"$STDERR" &
    else
        su -s /bin/sh -c "nohup $DAEMON -pidfile $PIDFILE $DAEMON_ARGS >>$STDOUT 2>>$STDERR &"
    fi

    # Add code here, if necessary, that waits for the process to be ready
    # to handle requests from services started subsequently which depend
    # on this one.  As a last resort, sleep for some time.
    sleep 1

    if /usr/bin/expressvpn status > /dev/null 2>&1; then
        return 0
    else
        return 2
    fi
}

#
# Function that stops the daemon/service
#
do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    if command -v start-stop-daemon > /dev/null 2>&1; then
        start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile "$PIDFILE" --name "$NAME"
           
        RETVAL="$?"
        [ "$RETVAL" = 2 ] && return 2
        # Wait for children to finish too if this is a daemon that forks
        # and if the daemon is only ever run from this initscript.
        # If the above conditions are not satisfied then add some other code
        # that waits for the process to drop all resources that could be
        # needed by services started subsequently.  A last resort is to
        # sleep for some time.
        start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
        [ "$?" = 2 ] && return 2
        # Many daemons don't delete their pidfiles when they exit.
        rm -f "$PIDFILE"
        return "$RETVAL"
    else
        # Stop the daemon.
        if [ -e "$PIDFILE" ]; then
            local PID
            PID="$(pgrep -f "$PIDFILE")"
            if test ! -z "$PID" && kill -0 "$PID" &>/dev/null; then
                if killproc -p "$PIDFILE" SIGTERM && /bin/rm -rf "$PIDFILE"; then
                    return 0
                else
                    return 2
                fi
            fi
        else
            return 1
        fi
    fi
}

case "$1" in
  start)
    log_daemon_msg "Starting $DESC" "$NAME"
    do_start
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  stop)
    log_daemon_msg "Stopping $DESC" "$NAME"
    do_stop
    case "$?" in
        0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
        2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
    esac
    ;;
  status)
    status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
    ;;
  restart)
    log_daemon_msg "Restarting $DESC" "$NAME"
    do_stop
    case "$?" in
      0|1)
        do_start
        case "$?" in
            0) log_end_msg 0 ;;
            1) log_end_msg 1 ;; # Old process is still running
            *) log_end_msg 1 ;; # Failed to start
        esac
        ;;
      *)
        # Failed to stop
        log_end_msg 1
        ;;
    esac
    ;;
*)
    log_action_msg "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" || true
    exit 1
    ;;
esac

:

Normally all I have to do is "dpkg -i <the .deb>" and "expressvpn activate" but with the funky .deb I get the following:

nobody@toshiba128:~$ expressvpn activate
Cannot connect to expressvpnd daemon.

It seems that the expressvpn daemon is not running. Please run "sudo service expressvpn restart" to start it.

If the problem persists, please contact us.

nobody@toshiba128:~$ sudo /etc/init.d/expressvpn restart
[FAIL] Restarting ExpressVPN service: expressvpnd failed!

Last edited by nobodyuknow (2021-01-09 18:05:40)

nobodyuknow · 2021-01-09 18:07:06

@zapper

I think substituting s6 for SysV is way beyond my talents.

Head_on_a_Stick · 2021-01-09 19:24:25

So what happens if you start it manually?

expressvpn status

Does that work or do you see any error messages?

Check if it's running with

pgrep -a expressvpn && echo 'It's running' || echo 'Not running'

Marjorie · 2021-01-10 00:09:15

Normally all I have to do is "dpkg -i <the .deb>" and "expressvpn activate"

This is my understanding:

The expression and syntax to enable and to start, stop, restart a service in sysvinit differ from those used by systemd

To enable expressvpn as a daemon in sysvinit you use:

sudo update-rc.d expressvpm defaults

This creates symbolic links in etc/c0.d ... etc/rc6.d, etc/rcS.d back to /etc/init.d/expressvpn that then start (and stop) expressvpm in the run levels defined in /etc/init.d/expressvpn when the OS starts.

Once you have enabled expressvpn you can then use:

sudo service expressvpn start|stop|restart|status|reload|force-reload

to make changes on the fly.

You can disable a service with

 sudo update-rc.d expressvpm remove

This removes the symbolic links, however you need to have removed /etc/init.d/expressvpn first.

zapper · 2021-01-10 06:08:58

nobodyuknow wrote:

@zapper
I think substituting s6 for SysV is way beyond my talents.

It might be beyond mine too, never used it... I have used runit/runit-init and openrc.

Although, never tried s6 cause i hear it is a replacement for systemd thats less bloated. Thus, you get the idea...

Head_on_a_Stick · 2021-01-10 10:07:15

Marjorie wrote:

To enable expressvpn as a daemon in sysvinit you use

I'm fairly sure that the postinst script for the .deb package will do that automatically via dh_installinit(1).

Marjorie · 2021-01-10 11:03:00

Head_on_a_Stick wrote:

Marjorie wrote:
To enable expressvpn as a daemon in sysvinit you use
I'm fairly sure that the postinst script for the .deb package will do that automatically via dh_installinit(1).

It should, if the sysvinit defaults has been set up when configuring the deb and the systemd default is also to enable. However some packages don't always enable by default - if the installation instructions explicitly tell you to enable the deamon then it won't have done it in the postinst script.
For example the nftables deb (another deb that doesn't install an /etc/init.d/nftables) also doesn't enable nftables by default even if you are using systemd.

Quite frequently when only systemd services are enabled and therefore /etc/inti.d/initscript is not included then the sysvinit postinit and postrm elements are not included either.

What I would suggest is that the OP either rerun update-rc.d, or at least check if their particular daemon has been enabled by looking to see if the synlinks are there.

You can also inspect the deb using gdebi. You'll find the postinst script in the 'installed files tab'. It should include something like this (taken from the chrony deb):

# Automatically added by dh_installinit/12.1.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
	if [ -x "/etc/init.d/chrony" ]; then
		update-rc.d chrony defaults >/dev/null
		if [ -n "$2" ]; then
			_dh_action=restart
		else
			_dh_action=start
		fi
		invoke-rc.d --skip-systemd-native chrony $_dh_action || exit 1
	fi
fi
# End automatically added section

Last edited by Marjorie (2021-01-10 11:03:57)

bgstack15 · 2021-01-11 13:19:09

There is coming eventually to Devuan Ceres a "systemctl" script that will translate the systemctl commands into real service commands. Ceres is the unstable release, and I doubt our devuan-sanity-systemctl package will ever reach a stable release, but it has the potential to solve this issue for folks who can use the unstable release.

Last edited by bgstack15 (2021-01-11 13:20:09)

nobodyuknow · 2021-01-11 22:10:08

@Head_on_a_Stick

Okay, I'm back. My Internet access on the weekend is limited.

nobody@toshiba128:~$ expressvpn status
Cannot connect to expressvpnd daemon.

It seems that the expressvpn daemon is not running. Please run "sudo service expressvpn restart" to start it.

If the problem persists, please contact us.

nobody@toshiba128:~$ pgrep -a expressvpn && echo 'It's running' || echo 'Not running'
>

nobodyuknow · 2021-01-11 22:13:15

@Marjorie

nobody@toshiba128:~$ sudo update-rc.d expressvpn defaults
nobody@toshiba128:~$
nobody@toshiba128:~$ sudo service expressvpn restart
[FAIL] Restarting ExpressVPN service: expressvpnd failed!

I think the latest expressvpn .deb is hosed with respect to non-systemd systems.

Last edited by nobodyuknow (2021-01-11 22:15:37)

ralph.ronnquist · 2021-01-11 23:33:48

The init script you installed is fine, but there is obviously a problem for the expressvpnd daemon program.

Try running /usr/sbin/expressvpnd from the command line; it may tell you why it fails to start.

Perhaps you are using apparmor restrictively and it needs some permissions set up?

chris2be8 · 2021-01-12 17:19:20

nobodyuknow wrote:

@Head_on_a_Stick

nobody@toshiba128:~$ pgrep -a expressvpn && echo 'It's running' || echo 'Not running'
>

The command you were given contains an odd number of quotes. Try

pgrep -a expressvpn && echo 'It is running' || echo 'Not running'

Chris

Head_on_a_Stick · 2021-01-12 20:22:16

^ Thanks Chris and apologies to the OP, I really should test my commands before posting. Or at least engage my brain before typing them.

nobodyuknow · 2021-01-13 17:30:05

@all

nobody@toshiba128:~$ pgrep -a expressvpn && echo 'It is running' || echo 'Not running'
Not running

nobody@toshiba128:~$ /usr/sbin/expressvpnd
<crickets>

Then I re-executed the first command, but I received the same result.

Last edited by nobodyuknow (2021-01-13 17:31:51)

Head_on_a_Stick · 2021-01-13 18:16:15

nobodyuknow wrote:

nobody@toshiba128:~$ /usr/sbin/expressvpnd
<crickets>

Crickets is good, we like crickets. In Unix-like systems the sound of crickets is the sound of success :-)

nobodyuknow wrote:

Then I re-executed the first command, but I received the same result.

Did you open another terminal to re-execute the pgrep command? You need to leave the expressvpn command running. Adding & to the end of the command would fork() it and return the prompt, this would let you close the terminal but keep the command running in the background.

ralph.ronnquist · 2021-01-13 21:30:01

Yes, "crickets" is a meaningful outcome. The follow-on testing would be

a) try running /usr/sbin/expressvpnd as root (I failed to highlight that before).

Then b) look into the end of the file /var/log/syslog for traces of that run; esp. if there is anything near a good statement of why it is failing. In particular, if it's an apparmor issue, then it would show up there I think.

Also b2), check whether there might be a dedicated log file for expressvpn in /var/log.

nobodyuknow · 2021-01-16 19:21:38

nobody@toshiba128:~$ sudo /usr/sbin/expressvpnd
restore: /etc/resolv.conf not generated by expressvpn
^C
nobody@toshiba128:~$

The end of /var/log/syslog didn't contain anything related to the above.

As I said before, I think the latest ExpressVPN .deb is pretty much incompatible with non-systemd systems. I'm marking this thread as solved because I have a work-around, i.e., use the previous .deb.

Last edited by nobodyuknow (2021-01-16 19:42:32)

zapper · 2021-01-17 04:14:10

nobodyuknow wrote:

nobody@toshiba128:~$ sudo /usr/sbin/expressvpnd
restore: /etc/resolv.conf not generated by expressvpn
^C
nobody@toshiba128:~$
The end of /var/log/syslog didn't contain anything related to the above.
As I said before, I think the latest ExpressVPN .deb is pretty much incompatible with non-systemd systems. I'm marking this thread as solved because I have a work-around, i.e., use the previous .deb.

And/Or in the future, use a different vpn which supports freedom more.

nobodyuknow · 2021-01-19 23:35:23

@zapper

Point taken, but:
- One only learns these things after one pays for it.
- ExpressVPN also has a problem with Manjaro, as they only test with Arch and expect Manjaro users to accept AUR.
- I first used ProtonVPN, but its commands require sudo while ExpressVPN commands do not. ProtonVPN eliminated its servers in my home city, which makes it problematic for websites requiring local login (Hotmail and my bank's website did not appreciate that).

Which VPNs are known to be compatible with Devuan?

The officially official Devuan Forum!

#1 2021-01-08 19:05:27

SOLVED: Devuan's "systemctl daemon-reload"

#2 2021-01-08 19:15:27

Re: SOLVED: Devuan's "systemctl daemon-reload"

#3 2021-01-08 22:20:55

Re: SOLVED: Devuan's "systemctl daemon-reload"

#4 2021-01-08 22:26:13

Re: SOLVED: Devuan's "systemctl daemon-reload"

#5 2021-01-08 22:50:18

Re: SOLVED: Devuan's "systemctl daemon-reload"

#6 2021-01-09 01:45:12

Re: SOLVED: Devuan's "systemctl daemon-reload"

#7 2021-01-09 18:04:49

Re: SOLVED: Devuan's "systemctl daemon-reload"

#8 2021-01-09 18:07:06

Re: SOLVED: Devuan's "systemctl daemon-reload"

#9 2021-01-09 19:24:25

Re: SOLVED: Devuan's "systemctl daemon-reload"

#10 2021-01-10 00:09:15

Re: SOLVED: Devuan's "systemctl daemon-reload"

#11 2021-01-10 06:08:58

Re: SOLVED: Devuan's "systemctl daemon-reload"

#12 2021-01-10 10:07:15

Re: SOLVED: Devuan's "systemctl daemon-reload"

#13 2021-01-10 11:03:00

Re: SOLVED: Devuan's "systemctl daemon-reload"

#14 2021-01-11 13:19:09

Re: SOLVED: Devuan's "systemctl daemon-reload"

#15 2021-01-11 22:10:08

Re: SOLVED: Devuan's "systemctl daemon-reload"

#16 2021-01-11 22:13:15

Re: SOLVED: Devuan's "systemctl daemon-reload"

#17 2021-01-11 23:33:48

Re: SOLVED: Devuan's "systemctl daemon-reload"

#18 2021-01-12 17:19:20

Re: SOLVED: Devuan's "systemctl daemon-reload"

#19 2021-01-12 20:22:16

Re: SOLVED: Devuan's "systemctl daemon-reload"

#20 2021-01-13 17:30:05

Re: SOLVED: Devuan's "systemctl daemon-reload"

#21 2021-01-13 18:16:15

Re: SOLVED: Devuan's "systemctl daemon-reload"

#22 2021-01-13 21:30:01

Re: SOLVED: Devuan's "systemctl daemon-reload"

#23 2021-01-16 19:21:38

Re: SOLVED: Devuan's "systemctl daemon-reload"

#24 2021-01-17 04:14:10

Re: SOLVED: Devuan's "systemctl daemon-reload"

#25 2021-01-19 23:35:23

Re: SOLVED: Devuan's "systemctl daemon-reload"

Board footer