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