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
