Since the service type is "simple" and the daemon is started with -f, the PIDFile is never actually used -- systemd takes care of putting the process in the background and managing it thereafter. This was brought to my attention in Gentoo bug 648992 because the associated tmpfiles.d entry in startup/tmpfile.conf.in contains,
d @piddir@ 0755 @nrpe_user@ @nrpe_group@ - -
That line is intended to make the directory containing PIDFile writable by the NRPE user and group, but as mentioned above, no PID file is needed when running the service in the foreground as nrpe_user/nrpe_group. When --piddir=/run is passed to the configure script, it can even break the permissions on /run by changing them from root:root to @nrpe_user@:@nrpe_group@.
So tl;dr my suggestion would be to,
Delete the PIDFile and ExecStopPost lines from the service file.
Drop tmpfiles.conf entirely.
That shouldn't affect systemd users at all, but it will prevent the tmpfiles.d entry from doing any harm.
The systemd service file startup/default-service.in contains (slightly edited),
Since the service type is "simple" and the daemon is started with
-f, thePIDFileis never actually used -- systemd takes care of putting the process in the background and managing it thereafter. This was brought to my attention in Gentoo bug 648992 because the associated tmpfiles.d entry in startup/tmpfile.conf.in contains,That line is intended to make the directory containing
PIDFilewritable by the NRPE user and group, but as mentioned above, no PID file is needed when running the service in the foreground as nrpe_user/nrpe_group. When--piddir=/runis passed to the configure script, it can even break the permissions on/runby changing them fromroot:rootto@nrpe_user@:@nrpe_group@.So tl;dr my suggestion would be to,
PIDFileandExecStopPostlines from the service file.tmpfiles.confentirely.That shouldn't affect systemd users at all, but it will prevent the tmpfiles.d entry from doing any harm.