net-analyzer/monitoring-plugins and net-analyzer/nagios-plugins: check_load don't find uptime path with >=sys-process/procps-3.3.11 With <sys-process/procps-3.3.11: /usr/lib64/nagios/plugins/check_load -w 18,15,10 -c 24,20,12 -r OK - load average: 0.07, 0.06, 0.04|load1=0.066;18.000;24.000;0; load5=0.063;15.000;20.000;0; load15=0.039;10.000;12.000;0; With >=sys-process/procps-3.3.11: /usr/lib64/nagios/plugins/check_load -w 18,15,10 -c 24,20,12 -r could not parse load from uptime: (null) The problem is that >=sys-process/procps-3.3.11 put uptime in /bin now. With <sys-process/procps-3.3.11 uptime was in /usr/bin. So a temporary fix is to create a link: lrwxrwxrwx 1 root root 11 Nov 11 13:02 /usr/bin/uptime -> /bin/uptime
Thanks Zentoo for the report. You don't have to create a link, enough to rebuild the package. mjo, I think we could add a dep on procps: sys-process/procps:= What do you think?
The path to `uptime` is hard-coded in the plugin, but both locations are correctly detected when you're compiling nagios-plugins or monitoring plugins. Try re-emerging nagios/monitoring-plugins, it should pick up the new location.
(In reply to Tomas Mozes from comment #1) > Thanks Zentoo for the report. > > mjo, I think we could add a dep on procps: sys-process/procps:= > There's a comment in the procps ebuild, SLOT="0/5" # libprocps.so that makes me think the subslot version will be tied to that library. I don't want to force people to re-emerge nagios-plugins every time that library changes, because we're not using the library... On the other hand, we don't have a better way to say that we need to rebuild when an executable moves around. So honestly I don't know.
(In reply to Tomas Mozes from comment #1) > Thanks Zentoo for the report. > > You don't have to create a link, enough to rebuild the package. > > mjo, I think we could add a dep on procps: sys-process/procps:= > > What do you think? I confirm that re-emerge net-analyzer/monitoring-plugins (so I suppose net-analyzer/nagios-plugins too) solve it without the need of a link. I think the problem is really the hardcoded path that is detected at configuration time. It should use classical detection through PATH environment variable. So this is more an upstream problem. For a solution at gentoo level, I think that we need to add a einfo to procps-3.3.11* ebuild to tell users to re-emerge net-analyzer/monitoring-plugins or net-analyzer/nagios-plugins if it's installed and the procps upgrade come from a pre-3.3.11 version. This way you don't have to recompile each time monitoring plugins but only once when you upgrade procps.
(In reply to Zentoo from comment #4) > > For a solution at gentoo level, I think that we need to add a einfo to > procps-3.3.11* ebuild to tell users to re-emerge > net-analyzer/monitoring-plugins or net-analyzer/nagios-plugins if it's > installed and the procps upgrade come from a pre-3.3.11 version. > It's not clear that procps should have changed the location of `uptime` -- that's bug #565304. I agree it would be nice if the detection happened at runtime, but for now we should probably just wait and see what happens in that other bug.
there's no good reason to hardcode the full paths. use execvp/execlp to locate the program instead.
Seems like commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7076fa1abfb1ad28304e00d5166e00e998edc7c3 reverted the paths back in procps. However I agree with Mike that this should be reported upstream.
That have been reported upstream and I've added a comment about potential issues: https://github.com/monitoring-plugins/monitoring-plugins/issues/1394
Reported upstram for nagios-plugins too: https://github.com/nagios-plugins/nagios-plugins/issues/124
Monitoring-plugins upstream does not like the idea of using, for example, execvp/execlp as runtime path detection. Any ideas how to handle this situation? Keep it as is or dep on procps:= ?
(In reply to Tomáš Mózes from comment #10) > Monitoring-plugins upstream does not like the idea of using, for example, > execvp/execlp as runtime path detection. > > Any ideas how to handle this situation? Keep it as is or dep on procps:= ? How many other packages would need subslots dependencies to get it right (how many other program paths are detected at build-time)? From the ./configure script I see at least, * net-dns/bind-tools(/usr/bin/nslookup) * sys-process/procps (/usr/bin/uptime) * net-nds/rpcbind (/usr/bin/rpcbind) * net-fs/samba (/usr/bin/smbclient) * net-misc/openssh (/usr/bin/ssh) * app-admin/sudo (/usr/bin/sudo) and I don't know what to do about /usr/bin/mailq. If upstream doesn't want to do runtime detection, we really only have two options: 1) subslots deps on everything detected at build-time 2) do nothing and hope it doesn't happen again Since this was accidental, and (as far as I know) we don't expect it to happen again, I can take #2 and still sleep at night. The first is technically correct for the existing build system, but a little annoying.
Last unstable version (3.3.11-r3) have put back uptime and other binaries in /usr/bin/ So this problem shouldn't annoyed anymore gentoo users. Only unstable users that have compiled >=procps with version 3.3.11 prior to -r3 revision have to recompile theirs nagios plugins or monitoring plugins. Stable users won't see this problem. That's about the gentoo point of view. The real problem stay an upstream problem about how to find binaries path.
I agree, let's close this for now. Thanks for looking into this.
