Hi, in short: how to use "init.d" scripts on Debian?
in detail: On one server a init.d script with LSB header does not work, at least when started by command line. I traced down the following: #1 init.d/script sources /lib/lsb/init-functions #2 /lib/lsb/init-functions has support for hooks: # Include hooks from other packages in /lib/lsb/init-functions.d for hook in $(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 2>/dev/null); do [ -r $hook ] && . $hook || true done and, among others, sources /lib/lsb/init-functions.d/40-systemd #3 /lib/lsb/init-functions.d/40-systemd first implements some anti-debugging technique by checking PPID for being init to ensure that testing on command line might gain different results than interactive testing: # Redirect SysV init scripts when executed by the user if [ $PPID -ne 1 ] && [ -z "${init:-}" ] && [ -z "${_SYSTEMCTL_SKIP_REDIRECT:-}" ]; then then seem to check if a service unit with same name as init.d script can be used instead (I guess): case $(readlink -f "$0") in /etc/init.d/*) _use_systemctl=1 # Some services can't reload through the .service file, # but can through the init script. prog=${0##*/} service="${prog%.sh}.service" if [ "$(systemctl -p CanReload show $service 2>/dev/null)" = "CanReload=no" ] && [ "${1:-}" = "reload" ]; then _use_systemctl=0 fi ;; esac for some reason use_systemctl=0 is set back only if second parameter is "reload", so when it is e.g. "start", use_systemctl remains 1 in my case. #4 /lib/lsb/init-functions.d/40-systemd then with use_systemctl=1 performs: if [ "$_use_systemctl" = "1" ]; then # Some init scripts use "set -e" and "set -u", we don't want that # here set +e set +u if [ "x$1" = xstart -o \ "x$1" = xstop -o \ "x$1" = xrestart -o \ "x$1" = xreload -o \ "x$1" = xforce-reload -o \ "x$1" = xstatus ] ; then systemctl_redirect $0 $1 exit $? fi fi which in my case fails with: +++ /bin/systemctl start gitlab-runner.service Failed to start gitlab-runner.service: Unit gitlab-runner.service failed to load: No such file or directory. (just for the records, I like "set -e" and I do want that in general). As a workaround / hack I set DPKG_MAINTSCRIPT_PACKAGE=HACK_ACTIVE. In contrast to my expectation, the scripting then did not do nothing as expected and let the main script work, but instead /bin/systemctl start gitlab-runner.service was still executed but now successfully! It seems that the "hook" as a side effect changes my system if for example DPKG_MAINTSCRIPT_PACKAGE=NO is set, can this be the case? My questions: 1) How is this supposed to work? Is this some systemd hack that generates some virtual service units because systemd actually cannot run init.d scripts correctly? 2) Why do I need to set DPKG_MAINTSCRIPT_PACKAGE? Where is it documented how DPKG_MAINTSCRIPT_PACKAGE influences systemd? 3) Why does systemd depend on DPKG_MAINTSCRIPT_PACKAGE? Is this a systemd generic or a Debian 8 specific dependecy? 4) Is DPKG_MAINTSCRIPT_PACKAGE set by dpkg during installation, so that the hack normally is invisible as long as not installing packages in any different way (i.e. no "make install")? and most important: 5) How to install, use, maintain and run init.d scripts at all? I have the feeling that every time I'm facing a problem with running a little simple daemon since a couple of years I end up in debugging script code over script code, so I'm doing it wrong (and so do the packages I use). How to do it right? I'm afraid this depends on the Debian version as well, so what works for Debian 8 can fail with Debian 10. Is there some documentation explaining how to do that, how to maintain init.d scripts for Debian or even "Linux" in general? Any hints / links appreciated. Steffen