[systemd-devel] sd_watchdog_enabled: how to use when forking process?

Lennart Poettering lennart at poettering.net
Mon Jan 22 12:59:59 UTC 2018


On Fr, 19.01.18 17:41, Simon McVittie (smcv at collabora.com) wrote:

> On Fri, 19 Jan 2018 at 17:22:51 +0000, philip is hungry wrote:
> > however if i run the forkme function (to put process in the background) it
> > behaves as follows:
> > 
> > Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228
> > Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0
> > Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid:
> > 11228
> 
> systemd tells your service which process it expects to be sending
> keepalives ($WATCHDOG_PID), and only accepts keepalives from that
> process.

This is not fully correct. We accept keepalives from every process
that NotifyAccess= whitelists... If not specified it will only allow
them from the service's main process, which is the same as the one
indicated in $WATCHDOG_PID, but this is not true for the general
case...

But yeah, in general Simon is right: don't fork if you don#t have
to. And if you do: use NotifyAccess= and make sure that WATCHDOG_PID
matches what you expect then.

(the reason why $WATCHDOG_PID exists is to cancel the usual
inheritance effect of env vars: if we would not set it, and you have
an app that would generically ping $NOTIFY_SOCKET if $WATCHDOG_USEC is
set, then this app called from some arbitrary child process of the
daemon might feel requested to ping PID 1 even though it was only
daemon itself that was supposed to do that...)

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list