check_load hardcodes path to 'uptime' (#1394)

[Michael Orlitzky]

@glensc The problem was with a new version of procps that became available
to users who already had monitoring-plugins installed. When they upgraded
procps (to a version that didn't exist when we packaged the plugins), the
plugins broke and there was nothing we could do about it. The plugin
maintainers don't also maintain procps, samba, SSH, etc. so we won't get any
warning before paths change.

We can fix it in the future with "blocker" deps but it's sort of pointless.
If we're going to force users to reinstall a new version of the plugins that
blocks some procps -- well, the reinstall itself fixes the problem, because
the plugins get rebuilt and find the correct executable paths!

@waja I can imagine a scenario where runtime detection could do something
wrong, but right now, the "build-time detection" is just runtime
detection... at build-time. When users install the plugins, the
`./configure` picks up whatever path happens to work at the time and then
hard-codes that. So if mischief can occur with the paths it could still
affect a compiled-in path.

We may just have to force users to reinstall the plugins frequently (or do
nothing and ignore the problem =)

I see a few other hard-coded paths for nslookup, ssh, rpcinfo, mailq,
smbclient,... Monitoring-plugins would need to be recompiled every time one
of those packages is updated, so it comes down to what would be most
annoying in the long run. I'm leaning slightly towards "do nothing" as that
is my default mode.

-- 
Reply to this email on GitHub:
https://github.com/monitoring-plugins/monitoring-plugins/issues/1394#issuecomment-186461049
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20160219/6f8a655f/attachment.html>