The hardcoded override paths (/bin/ping and /bin/ping6) in /usr/portage/net-analyzer/nagios-plugins/nagios-plugins-2.4.2.ebuild are incompatible with net-misc/iputils-20221126. Reproducible: Always Steps to Reproduce: 1. install =net-analyzer/nagios-plugins/nagios-plugins-2.4.2 2. install =net-misc/iputils-20221126 3. run nagios Actual Results: [1669823937] HOST ALERT: mega.mega.nu;DOWN;HARD;3;CRITICAL - Could not interpret output from ping command Expected Results: [1669824556] HOST ALERT: mega.mega.nu;UP;HARD;1;PING OK - Packet loss = 0%, RTA = 0.04 ms This patch fixes the problem for me: diff -up /usr/portage/net-analyzer/nagios-plugins/nagios-plugins-2.4.2.ebuild /etc/portage/overlay/net-analyzer/nagios-plugins/nagios-plugins-2.4.2-r1.ebuild --- /usr/portage/net-analyzer/nagios-plugins/nagios-plugins-2.4.2.ebuild 2022-11-19 17:40:43.000000000 -0600 +++ /etc/portage/overlay/net-analyzer/nagios-plugins/nagios-plugins-2.4.2-r1.ebuild 2022-11-30 10:17:30.428258276 -0600 @@ -84,10 +84,20 @@ src_configure() { # The autodetection for these two commands can hang if localhost is # down or ICMP traffic is filtered. Bug #468296. - myconf+=( --with-ping-command="/bin/ping -n -U -w %d -c %d %s" ) + if ping_path=$(command -v ping); then + myconf+=( --with-ping-command="${ping_path} -n -U -w %d -c %d %s" ) + else + ewarn "couldn't find path for ping -- defaulting to /bin/ping." + myconf+=( --with-ping-command="/bin/ping -n -U -w %d -c %d %s" ) + fi if use ipv6; then + if ping6_path=$(command -v ping6); then + myconf+=( --with-ping6-command="${ping6_path} -n -U -w %d -c %d %s" ) + else + ewarn "couldn't find path for ping6 -- defaulting to /bin/ping6." myconf+=( --with-ping6-command="/bin/ping6 -n -U -w %d -c %d %s" ) + fi fi econf \
Note that net-analyzer/nagios-core-4.4.8/work/nagios-4.4.8/sample-config/cgi.cfg also has /bin/ping hardcoded in it.
Is your system usr merged?
I have only a dim memory of the news item around that. IIRC I followed the advice, but can you remind me how to check if I did?
(In reply to Daniel Pouzzner from comment #3) > I have only a dim memory of the news item around that. IIRC I followed the > advice, but can you remind me how to check if I did? Could you share emerge --info and ls -al /?
Created attachment 838637 [details] emerge --info
ls -al /, omitting irrelevant local mountpoints: total 2353 drwxr-xr-x 1 root root 380 Jul 28 18:34 . drwxr-xr-x 1 root root 380 Jul 28 18:34 .. drwxr-xr-x 1 root root 1190 Nov 30 10:34 bin drwxr-xr-x 7 root root 1024 Nov 26 10:14 boot drwxr-xr-x 20 root root 5580 Nov 30 01:49 dev drwxr-xr-x 1 root root 7020 Nov 30 13:41 etc drwxr-xr-x 1 root root 154 Feb 24 2022 home drwxr-xr-x 1 root root 24 Aug 20 2019 hosts drwxr-xr-x 1 root root 110 Oct 31 2017 init drwxr-xr-x 1 root root 890 Nov 28 09:38 lib drwxr-xr-x 1 root root 4848 Nov 30 10:05 lib64 drwx------ 1 root root 0 Oct 15 2017 lost+found drwxr-xr-x 1 root root 10 Oct 11 2017 media drwxr-xr-x 1 root root 200 Mar 13 2021 mnt drwxrwxr-t 1 root root 816 Nov 21 15:28 opt dr-xr-xr-x 1229 root root 0 Nov 2 23:11 proc drwx------ 1 root root 2020 Nov 30 17:01 root drwxr-xr-x 49 root root 2060 Nov 30 11:50 run drwxr-xr-x 1 root root 5044 Nov 28 10:14 sbin dr-xr-xr-x 12 root root 0 Nov 2 23:11 sys drwxrwxrwt 773 root root 16100 Nov 30 17:01 tmp drwxr-xr-x 1 root root 972 Jul 6 12:36 usr drwxr-xr-x 1 root root 164 May 28 2022 var
Hard-coded /bin/ping was there before I took over as maintainer. It probably should have been $(command -v ping) all along. I'll just switch it. The point of passing --with-ping-command isn't to avoid the $PATH autodetection, but to avoid the configure script *running* ping to probe for the right arguments.
Ah, Sam I think I see the relevant thing you were getting at, in make.conf: USE="[...] split-usr [...]" So yes I have that set globally.
Michael: yup.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=51148f5256d4c1d10138f967a884a6f7aa58fdca commit 51148f5256d4c1d10138f967a884a6f7aa58fdca Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-11-30 23:20:19 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-11-30 23:27:07 +0000 net-analyzer/nagios-plugins: use ping/ping6 from $PATH in v2.4.2. We pass explicit ping/ping6 commands to the nagios-plugins ./configure script to prevent it from running those commands during the build. However, instead of grabbing their paths from $PATH, we have (until now) hard-coded them to /bin/ping and /bin/ping6. This has now bitten us with net-misc/iputils-20221126. This commit uses $(command -v ...) to get the right absolute paths. Thanks to Daniel Pouzzner for reporting the problem and suggesting the fix. Closes: https://bugs.gentoo.org/883765 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> net-analyzer/nagios-plugins/nagios-plugins-2.4.2.ebuild | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Thanks, v2.4.2 should do the right thing now. I left off the ewarns because in any reasonable scenario, they'll be redundant. And really, the installation should bail out at that point if ping can't be found because otherwise the installed package will be broken (no path or wrong path, all the same) and will cause nagios to send a million alerts.
>the installation should bail out at that point if ping can't be found Quite right. Preserving the old behavior as a fallback was just my overly cautious code.
Isn't a new revision needed given it's broken at runtime if it hardcoded the wrong path?
(In reply to Sam James from comment #13) > Isn't a new revision needed given it's broken at runtime if it hardcoded the > wrong path? I'm not against it, but everyone is going to have to manually rebuild nagios-plugins anyway (when they notice their host checks start failing), because the upgrade to iputils won't trigger it. WDYT?
net-misc/iputils-20221126 is ~amd64 (etc) now. So you can push an -r1 that's ~amd64, since we unstable users expect that sort of churn. Do you have a way to make sure that the fixed nagios-plugins can go stable before/when the new iputils goes stable?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5112807f49a3c719010b5894614cbbe77085c9cd commit 5112807f49a3c719010b5894614cbbe77085c9cd Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-12-01 00:03:08 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-12-01 00:07:44 +0000 net-analyzer/nagios-plugins: new revision to trigger a rebuild. Anyone whose "ping" has moved will want to rebuild this after the latest fix. Doing so right now won't help everybody (e.g. if nagios-plugins is upgraded before iputils), but it's an easy rebuild and will help *some* people, so I think it's worth it. Thanks to Sam for the suggestion. Bug: https://bugs.gentoo.org/883765 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../{nagios-plugins-2.4.2.ebuild => nagios-plugins-2.4.2-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Daniel Pouzzner from comment #15) > net-misc/iputils-20221126 is ~amd64 (etc) now. So you can push an -r1 > that's ~amd64, since we unstable users expect that sort of churn. Yeah I decided to take my own advice: if you have to think about it, don't; do a revbump. > Do you have a way to make sure that the fixed nagios-plugins can go stable > before/when the new iputils goes stable? I think what we actually want is for them to both go stable at exactly the same time, so that emerge -puDN @world will pull in the new iputils, and then later (in the same batch) pull in the new nagios-plugins. There's no easy way to do that, except to coordinate the stablereqs.
Bah, this is messy. I'm just realizing, what you'd need to do is force a reinstall of nagios-plugins if iputils is upgraded under it, ideally only for an upgrade from pre-20221126 to 20221126+. I know I don't know how to express that in ebuild-speak... And note this applies to 2.4.0 also -- in principle you might need to push out a 2.4.0-r1 with the fix, born stable, to replace the current 2.4.0, and that one you would indeed ideally push out simultaneous with iputils-20221126+ going stable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48c0881d8fd0646146890c23741634924cf15eba commit 48c0881d8fd0646146890c23741634924cf15eba Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-12-01 00:16:58 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-12-01 00:18:34 +0000 net-analyzer/nagios-plugins: another revision to fix a botched commit. Somehow I managed to delete an important part of the ebuild in what should have been a trivial revision during the last commit. Let's undo that. Bug: https://bugs.gentoo.org/883765 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../{nagios-plugins-2.4.2-r1.ebuild => nagios-plugins-2.4.2-r2.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Daniel Pouzzner from comment #18) > Bah, this is messy. I'm just realizing, what you'd need to do is force a > reinstall of nagios-plugins if iputils is upgraded under it, ideally only > for an upgrade from pre-20221126 to 20221126+. I know I don't know how to > express that in ebuild-speak... > > And note this applies to 2.4.0 also -- in principle you might need to push > out a 2.4.0-r1 with the fix, born stable, to replace the current 2.4.0, and > that one you would indeed ideally push out simultaneous with > iputils-20221126+ going stable. I was just about to do that when I noticed I botched the last commit. Incoming...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=51a16efe55c6bd5e7d1d98060fa59d661cd4f656 commit 51a16efe55c6bd5e7d1d98060fa59d661cd4f656 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-12-01 00:21:16 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-12-01 00:21:16 +0000 net-analyzer/nagios-plugins: revbump to trigger a stable rebuild. On the off chance that anyone is using stable nagios-plugins with an ~arch iputils, we trigger a rebuild to avoid nagios going haywire when "ping" moves. Bug: https://bugs.gentoo.org/883765 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../{nagios-plugins-2.4.0.ebuild => nagios-plugins-2.4.0-r1.ebuild} | 0 1 file changed, 0 insertions(+), 0 deletions(-)
I'll preemptively file a stable bug (with no arches for a while yet, obviously) for iputils + nagios-plugins + monitoring-plugins.
(In reply to Sam James from comment #22) > I'll preemptively file a stable bug (with no arches for a while yet, > obviously) for iputils + nagios-plugins + monitoring-plugins. Ok, thanks, I'm going to go do the same things to monitoring-plugins now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d465e3780420afcaeeb5e9e76d1bbb5428d94f5 commit 1d465e3780420afcaeeb5e9e76d1bbb5428d94f5 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-12-01 00:31:18 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-12-01 00:33:39 +0000 net-analyzer/nagios-plugins: yet another ping-related stable revision. It turns out that the new revision to force a rebuild doesn't help unless you actually include the path detection fix along with it. Bug: https://bugs.gentoo.org/883765 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> ...gios-plugins-2.4.0-r1.ebuild => nagios-plugins-2.4.0-r2.ebuild} | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
Please ignore the six commits it took make to make two commits :) I'm not in my normal quiet & peaceful surroundings that I'd want to do this in but I think it's important to get a fix out ASAP.
