MX 23 without systemd: how to get wsdd to autostart [Solved]

[FadeToGrey]

Hello there,

I am posting this here since I use the KDE version of MX, butg I suspect this issue affects MX23 in general.
Initially this was supposed to be a request for help, but after digging through the issue I can present a solution instead :-)

Anyway, if you do a fresh install of wsdd on MX23, it does not start automatically, at least as long as SysVinit is used. The only post here in the forum that mentions this issue is http://forum.mxlinux.org/viewtopic.php? ... ee#p729831 - which means this issue exists since at least MX23beta2. wsdd itself however works.

The basic cause of this is that the wsdd package presented in the MX23 installer does not add the required init script to init.d. This seemed easy at first, so I dug out the one from https://mxrepo.com/mx/testrepo/pool/tes ... ian.tar.xz, copied the file to /etc/init.d, renamed it to "wsdd", changed user and group to root and made the file executable. Then I used sysv-rc-conf to set the init levels. After a reboot, the init script had failed to start but ran when I started it manually. Since neither wsdd nor the init script I used care about adding anything to a log file, I could not see what happened. Uninstalling everything and installing the whole MX21 .deb package did not help either.

Thus, I rather blindly went on with my 2nd attempt and compared what I had installed with the data on https://github.com/christgau/wsdd/releases/tag/v0.7.1 in the hope to find some error. There is no SysVinit script provided, but the openrc init script looked reasonably similar to me to give it a try and create a new SysVinit script - and it has a nice algorithm to extract the workgroup from the Samba settings which the MX21 init script lacked. Additionally, I removed root as wsddd user (does not seem to be required, actually the author of wsdd encourages to use a user with low access rights) and added some basic logging features. You might clean it up a bit, but it works and logs correctly:

Code: Select all

#!/bin/bash

### BEGIN INIT INFO
# Provides:         wsdd
# Required-Start:   $syslog $local_fs $remote_fs $network $named $time samba-ad-dc
# Required-Stop:    $syslog $local_fs $remote_fs $network $named $time samba-ad-dc
# Default-Start:    2 3 4 5
# Default-Stop:     0 1 6
# Short-Description: Web Services Dynamic Discovery host daemon
# Description: Web Services Dynamic Discovery (WSDD) host daemon
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DAEMON_NAME=wsdd
SMB_CONFIG_FILE=/etc/samba/smb.conf
LOG_FILE=/var/log/$DAEMON_NAME.log
WSDD_EXEC=/usr/sbin/$DAEMON_NAME
RUN_AS_USER=daemon
DESC="Web Services Dynamic Discovery host daemon"
PROCESSDIR=/var/run/$DAEMON_NAME
PIDFILE=/var/run/wsdd.pid

# get defaults file; edit that file to configure this script.
if test -e /etc/default/$DAEMON_NAME ; then
  . /etc/default/$DAEMON_NAME
fi

# Exit if the daemon is not installed
[ -x $WSDD_EXEC ] || exit 0

# load init-functions
[ -f /lib/init/vars.sh ] && . /lib/init/vars.sh
[ -f /lib/lsb/init-functions ] && . /lib/lsb/init-functions

# start command
do_start() {
	log_daemon_msg "Starting $DESC" "$DAEMON_NAME"
	OPTS="${WSDD_PARAMS} --chroot=${PROCESSDIR} --shortlog"

	if [ -z "$WSDD_WORKGROUP" ]; then
		# try to extract workgroup with Samba's testparm
		if which testparm >/dev/null 2>/dev/null; then
			GROUP="$(testparm -s --parameter-name workgroup 2>/dev/null)"
		fi

		# fallback to poor man's approach if testparm is unavailable or failed for some reason
		if [ -z "$GROUP" ] && [ -r "${SMB_CONFIG_FILE}" ]; then
			GROUP=`grep -i '^\s*workgroup\s*=' ${SMB_CONFIG_FILE} | cut -f2 -d= | tr -d '[:blank:]'`
		fi

		if [ -n "${GROUP}" ]; then
			OPTS="-w ${GROUP} ${OPTS}"
		fi
	else
		OPTS="-w ${WSDD_WORKGROUP} ${OPTS}"
	fi

	if [ ! -r "${LOG_FILE}" ]; then
		touch "${LOG_FILE}"
	fi
	# change owner of log file to user running wsdd - commented out for now since wsdd itself does not log anything
	# chown ${RUN_AS_USER} "${LOG_FILE}"

    # Ensure PROCESSDIR exists and is accessible
    install -o root -g root -m 755 -d $PROCESSDIR

	start-stop-daemon --start --background --user ${RUN_AS_USER} --make-pidfile --pidfile $PIDFILE --exec ${WSDD_EXEC} -- ${OPTS}
	# direct logging of wsdd output does not work due to the "--background" option which seems needed since the program does not detach itself. A log file other than stdout cannot be defined either :-(
	# crude replacement to log at least something...:
	RETVAL="$?"
	CURRENTDATE=`date +"%F %T,%N"`
	if [ $RETVAL -eq 0 ]; then
		echo "$CURRENTDATE wsdd started successfully, option flags $OPTS" >> $LOG_FILE 2>&1
		exit 0
	else
		echo "$CURRENTDATE wsdd start error with option flags $OPTS, error code $RETVAL" >> $LOG_FILE 2>&1
		log_end_msg 1
        exit 1
	fi
	log_end_msg 0
}

# stop command
do_stop() {
	log_daemon_msg "Stopping $DESC" "$DAEMON_NAME"
	start-stop-daemon --stop --retry 2 --pidfile $PIDFILE
	# same log surrogate as above for stopping
	RETVAL="$?"
	CURRENTDATE=`date +"%F %T,%N"`
	if [ $RETVAL -eq 0 ]; then
		echo "$CURRENTDATE wsdd stopped successfully" >> $LOG_FILE 2>&1
	else
		echo "$CURRENTDATE wsdd stop error code $RETVAL" >> $LOG_FILE 2>&1
	fi
	# Wait a little and remove stale PID file
    sleep 1
    if [ -f $PIDFILE ] && ! ps h `cat $PIDFILE` > /dev/null
    then
        rm -f $PIDFILE
    fi
    log_end_msg 0
	#return "$RETVAL"
}


case "$1" in

    start)
        do_${1}
        ;;

    stop)
        do_${1}
        log_end_msg 0
        ;;

	reload)
        do_stop
        do_start
        log_end_msg 0
		;;

    restart|force-reload)
        do_stop
        sleep 1
        do_start
        ;;

    status)
        status_of_proc "$WSDD_EXEC" "$DAEMON_NAME"
        exit $?
        ;;

    *)
        echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}"
        exit 1
        ;;

esac
exit 0

This finally told me that while the links in the rc.* folders are there, the wsdd init script is not executed at all during boot.

Only after doing a sudo update-rc.d wsdd -f remove und sudo update-rc.d wsdd defaults, I finally got wsdd to run. It seems that sysv-rc-conf only adds the links in the rc.* folders but does not care at all about updating the .depend files or anything else that might be needed in case of a new init script, causing the custom script not to be run by init. (I am unsure if that is a bug or intended though...)

Thus in case someone else has that issue on MX23:

• install the MX23 package of wsdd

• create a new script named "wsdd" in /etc/init.d with the above contents

• then use update-rc.d as noted above to register that script.

Took me two days to figure that out, but I have learned a lot about init scripts now - and it works

(edit: replaced script with the correct version)

[CharlesV]

Welcome in and thank you for the info!

[FadeToGrey]

@CharlesV thanks! I did not find any "New member presentation" thread here, so I hope it was okay that I just fired that post without saying hello first ;-)

[FadeToGrey]

[deleted, double post]

[CharlesV]

@CharlesV thanks! I did not find any "New member presentation" thread here, so I hope it was okay that I just fired that post without saying hello first ;-)

No worries, its all good! :-)

[thomasl]

A useful write-up, thanks!

As it is not that rare that stuff works well under (or is designed for) systemd but needs some "help" under SysVinit... perhaps a Wiki page collecting such how-tos (even if it has mostly links to such forum posts) might be a good idea (I tried to check the Wiki re this and found nothing, but if such a page already exists then just ignore this).

[FadeToGrey]

A useful write-up, thanks!

As it is not that rare that stuff works well under (or is designed for) systemd but needs some "help" under SysVinit... perhaps a Wiki page collecting such how-tos (even if it has mostly links to such forum posts) might be a good idea (I tried to check the Wiki re this and found nothing, but if such a page already exists then just ignore this).

Thank you!

I switched to MX Linux just recently, after my SSD died and I felt I had collected enough knowledge about Linux in the last three years with Linux Mint to try something better ;-) - thus from the perspective of a relatively new user:
yes, such a Wiki (or at least a comprehensive help article about SysVinit) would be great. When searching the Internet, I found loads of information about non-systemd init systems, most of which however does not seem to apply to the SysVinit of MX. You can filter many of those if you add a "-chkconfig" to your web search, but it turned out difficult to find the right information nevertheless. I only got to use update-rc.d instead of sysv-rc-conf after I stumbled over a notice buried somewhere on a page about Ubuntu...

Oh, and could someone who knows more about how to do that than me forward the information to... well, wherever needed to maybe correct this in a future release of the wsdd package...? Or explain how to do this. The only option I could think of was contacting the author of wsdd on Github, so I opened an issue there, but I really don't know if this was correct.

[CharlesV]

Glad you jumped :-) .. I ran mint for a long tie before finding MX and personally I think the os is much better, with some GREAT dev's and support. (Mint was good at that too, but the Dev's here are rubbing elbows with all of us every day !)

So, first thing is to get acquainted with MX Package Installer and the MX Repos. It has been my experience that *many* of the packages here are SysvInt aware, and the dev's typically try very hard to make sure of that... As a result, loading from here is usually a much different ride then loading from some place else. (And wsdd is in there - enabled and I believe a more recent version in Test Repo too .)

If you still find the package isnt doing SysVint well, then a shout out about it in the software section or request section will typically get a dev looking at it to see whats up and a fix or information about how too. (And there is also a pretty good How Too / users Tips and Tricks section which has some great stuff in it as well.)

Rule of thumb is to look for packages first in the MX Package Installer - if something isnt there, you can also request it too. (our Dev's are AWESOME about responding to requests!! )

[FadeToGrey]

@CharlesV yes, that is how I do it. Always look into the system's repositories first, anything not being in there might need additional work to run. And I was really happy what I found there - much less side-loading than on Mint needed!

The only remaining obstacle is now a decent DNLA server since Pipewire does not support than yet, but that is another topic ;-)

In this case, there is no more recent package than the one in "active repositories" I installed, so I guess this might be of interest for the devs. I will add a post in the request section then, thanks a lot!

[CharlesV]