Created attachment 521348 [details] emerge --info of affected system In /usr/portage/net-analyzer/nrpe/nrpe-3.2.1.ebuild line 34, the configure line has the option: --with-piddir=/run \ This causes /usr/lib/tmpfiles.d/nrpe.conf to look like this: #Type Path Mode UID GID Age Argument d /run 0755 nagios nagios - - as the file in the source tree startup/tmpfile.conf.in looks like this: #Type Path Mode UID GID Age Argument d @piddir@ 0755 @nrpe_user@ @nrpe_group@ - - This all results in /run being owned by nagios:nagios instead of root:root, which breaks some things. In particular net-dns/pdns-recursor does not start if /run is not owned by root:root for some reason. Before I discovered that this was the culprit changing ownership of /run, I had some problems starting nrpe via service file, and I overrode the nrpe.service file so that it didn't specify a pid file. Since it's a simple non-forking service, it doesn't actually need one. I believe the fix would be to change --with-piddir to be set to /run/nrpe as it's evident that upstream nrpe doesn't expect to have this set to /run. The service file should also automatically point to the new location.
I reported the issue upstream... I think the easiest way to solve it is to drop the unnecessary tmpfiles.d entry. OpenRC users do want the PID file to be created (as root) in a directory that's owned by root:root, so changing --with-piddir to /run/nrpe would only halfway solve the problem. OpenRC now honors tmpfiles.d entries, so the permissions would get set wrong on /run/nrpe in that case.
Does the tmpfiles.d file even get installed by default with our ebuild? I don't get one on my machine, but I'm not using systemd.
Yes, It does not appear on an openrc system, but it does on a systemd system. I believe it's because nrpe's ./configure script detects the currently running init type at build time, and when it equals systemd, it sets src_tmpfile=tmpfile.conf (configure line 3819), while src_tmpfile remains unset when under any other init type. -Troy
(In reply to Troy Ablan from comment #3) > Yes, > > It does not appear on an openrc system, but it does on a systemd system. I > believe it's because nrpe's ./configure script detects the currently running > init type at build time, and when it equals systemd, it sets > src_tmpfile=tmpfile.conf (configure line 3819), while src_tmpfile remains > unset when under any other init type. > Thanks. That behavior is incorrect in the first place, because (for example) OpenRC uses the tmpfiles.d entries too. But the guesswork is in general a bad idea because it makes bugs like this hard to spot. I'll see if I can (a) disable all of the guessing so that the build is consistent, and (b) patch out the PID file line from the systemd service, because it doesn't look like upstream is going anywhere.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2ddfa65c2244d92429897a51b1d8a8e3dc8a92dc commit 2ddfa65c2244d92429897a51b1d8a8e3dc8a92dc Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-09-30 12:26:56 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-09-30 12:27:53 +0000 net-analyzer/nrpe: new revision to eliminate PID files with systemd. The NRPE systemd service is "simple," which means that it runs in the foreground. As a result, no PID file is needed to later kill it. Nevertheless, the systemd service file that ships with NRPE tries to create one. And in order to do that, it messes with some permissions (Gentoo bug 648992) that shouldn't be messed with. This commit adds a patch to remove the PID file from the service. A related problem that this revision fixes is the automagic detection of the operating system, distribution, and init system by the NRPE autotools. The new revision hard-codes all of these to "unknown," which should result in behavior that is consistent across machines. In particular, it should cause the problematic tmpfiles.d entry (associated with the PID file) to not be installed. Bug: https://bugs.gentoo.org/648992 Package-Manager: Portage-2.3.49, Repoman-2.3.10 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../files/nrpe-3.2.1-eliminate-systemd-pid.patch | 38 +++++++++ net-analyzer/nrpe/nrpe-3.2.1-r1.ebuild | 89 ++++++++++++++++++++++ 2 files changed, 127 insertions(+)
Can you please give that -r1 a try? I made some changes to the build system that I hope will prevent the tmpfiles.d entry from being installed (and that I hope won't break anything else...) I then added a custom patch to avoid creating the unused PID file in the first place.
