On Fr, 19.01.18 17:41, Simon McVittie (s...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel