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. The forked child process has some other process ID, so sd_watchdog_enabled() returns false for it. If you want to use the watchdog, don't fork and go to the background: it's unnecessary for systemd services. To notify systemd that your process is ready to receive requests (which was done via the double-fork trick in init-script-based init systems), a daemon that natively supports systemd features can use sd_notify() and Type=notify. If you want your service to continue to support non-systemd init systems, you might want to add a --no-fork command-line option and make the systemd unit's ExecStart use that option. For example, that's how it works for dbus-daemon, which needs to continue to default to forking for compatibility with what it does on non-Linux OSs or non-systemd init. Or, if your service will only ever run under systemd, you can make it not fork/background itself at all. smcv _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel