how to make systemd execute init.d script status statements?

[Juha Heinanen]

When I upgraded one of my wheezy hosts to jessie, I noticed that

/etc/init.d/<my own daemon> status

command stopped working.

Looks like systemd does not execute the statements in status) case of
the init script at all, but just checks if the daemon process exists.
My '/etc/init.d/<my own daemon> status' did much more, i.e., it checked
if the daemon was actually able to do some real work.

So far I have had no luck in finding the answer from the web.

-- Juha

[Darac Marjal]

On the face of it, this *should* still work. When you invoke
"/etc/init.d/example status", you're running the shell script directly -
that is, without any reference to systemd. Now, I don't remember the
details, but I seem to recall there being a command (which a skeleton
shell script might import from somewhere) that says "Is systemd running?
In which case pass the argument to that", but without seeing the
contents of your script I can't say if it's doing that.

Try adding "set -x" at the top of your script to help with debugging it?

>

--
For more information, please reread.

[Juha Heinanen]

Darac Marjal writes:

> On the face of it, this *should* still work. When you invoke
> "/etc/init.d/example status", you're running the shell script directly -
> that is, without any reference to systemd. Now, I don't remember the
> details, but I seem to recall there being a command (which a skeleton
> shell script might import from somewhere) that says "Is systemd running?
> In which case pass the argument to that", but without seeing the
> contents of your script I can't say if it's doing that.
>
> Try adding "set -x" at the top of your script to help with debugging
> it?

Thanks for your reply. I added 'set -x' at the top of the script and
got lots of debug lines starting with +. the relevant ones seem to be
these:

...
+++ local command=status
+++ case "$command" in
+++ service=sip-proxy.service
++++ systemctl -p LoadState show sip-proxy.service
+++ state=LoadState=loaded
+++ '[' LoadState=loaded = LoadState=masked ']'
+++ '[' status = status ']'
+++ /bin/systemctl status sip-proxy.service
...

That is, instead of the statements in /etc/init.d/sip-proxy status), it
runs 'bin/systemctl status sip-proxy.service'

The question is, is there any means to prevent systemd from highjacking
my status statements?

-- Juha

[Juha Heinanen]

Looking a bit further up in debug output, I see this:

+ . /lib/lsb/init-functions
+++ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
++ for hook in '$(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 2>/dev/null)'
++ '[' -r /lib/lsb/init-functions.d/20-left-info-blocks ']'
++ . /lib/lsb/init-functions.d/20-left-info-blocks
++ for hook in '$(run-parts --lsbsysinit --list /lib/lsb/init-functions.d 2>/dev/null)'
++ '[' -r /lib/lsb/init-functions.d/40-systemd ']'
++ . /lib/lsb/init-functions.d/40-systemd
+++ _use_systemctl=0
+++ '[' -d /run/systemd/system ']'
+++ '[' -n '' ']'
+++ '[' 20132 -ne 1 ']'
+++ '[' -z '' ']'
+++ '[' -z '' ']'
+++ case $(readlink -f "$0") in
++++ readlink -f /etc/init.d/sip-proxy
+++ _use_systemctl=1
+++ prog=sip-proxy
+++ service=sip-proxy.service
++++ systemctl -p CanReload show sip-proxy.service
+++ '[' CanReload=no = CanReload=no ']'
+++ '[' status = reload ']'
+++ '[' 1 = 1 ']'
+++ set +e
+++ set +u
+++ '[' xstatus = xstart -o xstatus = xstop -o xstatus = xrestart -o xstatus = xreload -o xstatus = xforce-reload -o xstatus = xstatus ']'
+++ systemctl_redirect /etc/init.d/sip-proxy status

I guess this systemctl_redirect command does the highjacking perhaps
because of _use_systemctl=1.

-- Juha

[Sven Joachim]

On 2016-05-16 21:36 +0300, Juha Heinanen wrote:

> When I upgraded one of my wheezy hosts to jessie, I noticed that
>
> /etc/init.d/<my own daemon> status
>
> command stopped working.
>
> Looks like systemd does not execute the statements in status) case of
> the init script at all, but just checks if the daemon process exists.

Actually it does a bit more than that, but the bottom line is that (for
scripts that source /lib/lsb/init-functions, which every init script in
Debian is supposed to do) /lib/lsb/init-functions.d/40-systemd ensures
that "/etc/init.d/<script> <action>" is redirected to
"systemctl <action> <script>.service" for the common values of <action>,
i.e. start, stop, restart, reload, force-reload, status. This is
usually what you want, but there is a magic environment variable that
lets you skip the redirect.

> My '/etc/init.d/<my own daemon> status' did much more, i.e., it checked
> if the daemon was actually able to do some real work.

Use "_SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/<my own daemon> status",
and your init script won't redirect to systemctl.

Cheers,
Sven

[Jonathan de Boyne Pollard]

> Looks like systemd does not execute the statements in status) case of the init script at all, but just checks if the daemon process exists. My '/etc/init.d/<my own daemon> status' did much more, i.e., it checked if the daemon was actually able to do some real work.
>
> So far I have had no luck in finding the answer from the web.

You will find the answer here:

*
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/unix-daemon-readiness-protocol-problems.html
* https://freedesktop.org/software/systemd/man/sd_notify.html
* https://freedesktop.org/software/systemd/man/systemd-notify.html
*
https://lists.freedesktop.org/archives/systemd-devel/2014-April/018797.html

If you want to make your daemon interoperate with systemd's status
mechanism to the extent of having custom status reports, you have to
modify your daemon to send readiness notification messages through a
socket to the systemd service manager. That way, not only will
"/etc/init.d/jh status" report your custom statuses, so too will
"systemctl status jh" and (possibly) so too will (some) GUI
administration tools.

To do this, you must write a service unit for your service. Sticking
with a van Smoorenbug rc script and relying upon the
systemd-sysv-generator to write a compatibility service unit on the fly
to encapsulate it won't work, for several reasons. For starters, the
generator doesn't generate Type=notify service units and uses
RemainAfterExit=true (which prevents detection of service abends).

[Juha Heinanen]

> If you want to make your daemon interoperate with systemd's status
> mechanism to the extent of having custom status reports, you have to
> modify your daemon to send readiness notification messages through a
> socket to the systemd service manager. That way, not only will
> "/etc/init.d/jh status" report your custom statuses, so too will
> "systemctl status jh" and (possibly) so too will (some) GUI
> administration tools.

Jonathan,

Thanks for your response. Looks like it is easier to include a new
case, e.g., real-status), to the init script and use that rather than
trying to make systemd to find out the real status of the service.

-- Juha