[Pkg-nagios-devel] Bug#879084: 879084: more info, and three possible fixes

Raphaël Halimi raphael.halimi at gmail.com
Tue Jan 15 01:18:05 GMT 2019


I stumbled upon this bug with another plugin (check_rpc). I don't think
it's related to #863399 at all.

After enabling debug in icinga.cfg, the error message states:

Can't locate utils.pm in @INC (you may need to install the utils module)
(@INC contains: /usr/lib/icinga [...]).

The problem is that the plugin looks for a library (utils.pm) which is
specific to Nagios plugins. Icinga in Debian defaults to use an embedded
Perl interpreter (ePN - Embedded Perl Nagios), and the required library
file is indeed present in the package monitoring-plugins-common;
unfortunately, it seems that during the Nagios -> Icinga fork, the @INC
path used by ePN has been changed from /usr/lib/nagios to
/usr/lib/icinga, whereas the monitoring-plugins-common still provides
utils.pm in the original /usr/lib/nagios directory.

Interestingly, when check_rpc (which does use FindBin) is run from the
command-line, it works fine, though. I'm not a PerlMonk, but by
comparing ePN's @INC and the system's default @INC (perl -e "print
\"@INC\""), I guess in that case, the plugin is happy to find one of
/usr/share/perl/5.24.1/Module/CoreList/Utils.pm or
/usr/share/perl/5.24.1/ExtUtils/Constant/Utils.pm (those are the only
ones on my system that are located in a directory not included in ePN's
@INC)n and don't actually require any function from monitoring-plugins'

It seems that quite a bunch of plugins should suffer from this problem;
a quick grep on "use utils" in /usr/lib/nagios/plugins/ gives:


To fix this bug without modifying every plugin, there are several solutions:

The one which seems the cleanest would be to modify Icinga's ePN source
code to add /usr/lib/nagios in @INC (since that's where utils.pm is
actually provided by monitoring-plugins-common) or even replace
/usr/lib/icinga, since this directory contains only a single file
"p1.pl", whose path is (correctly) set in /etc/icinga/icinga.cfg. I
don't know what /usr/lib/icinga is used for, since on my system it only
contains p1.pl.

Another solution would be to disable ePN completely, which would make
Icinga use the native Perl installation from the system. It's disabled
by default in upstream, but enabled by default in the Debian package by
the patch "debian/patches/52_icinga.cfg-debianize.patch"; the change was
introduced in 1.5.0-2 (according to the changelog), but the git log for
dab43df doesn't say anything more about the reason of that choice.

This would mean that the bug was present since at least Wheezy (which
has Icinga 1.7.1-7). I'm not sure how it went unnoticed for so long,
maybe people just enable debug, see what's wrong, quickly fix it (like
OP, or globally, see below) and go on without reporting it; or maybe
they just deem the impacted plugins as bugged and give up on them
completely (it's true that, if one doesn't enable debug, the web
interface doesn't say much apart of something like "the plugin died with
an error").

Anyway, note that the comment about ePN in /etc/icinga/icinga.cfg is
quite scary:

# This option is intentionally disabled by default, because embedded
# perl can cause memory leaks and make Icinga unstable if not properly
# used.
# Only enable this setting when you really know what you are doing!

On the other hand, this scary comment in not present in the equivalent
configuration file in Nagios 3 (in fact, I'm new to Icinga, because I
migrated an old Nagios installation on Jessie to a new Stretch box; I
don't have the required time right now to learn Icinga 2, so I went the
lazy way with Icinga 1).

I guess this comment dates from the times when Icinga was freshly
forked, and that ePN's stability has hugely since then; or maybe the
performance loss would be *really* huge without it; moreover, for the
years I used Nagios, this host never suffered any noticeable memory
leak, so I decided to trust the package maintainers' choice and let ePN
enabled, which brings us to the third solution: the quick and dirty
workaround I used on my system to make the plugin(s) work, which is to
simply symlink utils.pm in /usr/lib/icinga, so that ePN would find it in
its @INC.

Solution 1 may have unforeseen consequences, especially if you decide to
replace /usr/lib/icinga in @INC by /usr/lib/nagios; solution 2 may
result in a performance loss (maybe a huge one on big installations), so
the third one, which may look like a quick and dirty workaround, is in
fact the less intrusive; and since icinga-core depends on icinga-common,
which in turn depends on monitoring-plugins-basic, it would be safe for
one of those two packages to provide such a symlink.

In any case, apart of a fix in unstable, a bugfix release for Stretch
would be much appreciated, even if only two people complained about that
bug in 7 years... :)

Note that, for the sake of completeness, I also looked at the equivalent
for shell plugins (utils.sh), but they don't seem to suffer from the
same problem, since they source $PROGPATH/utils.sh, with $PROGPATH being
extracted from $0.

Hope it helps.


Raphaël Halimi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-nagios-devel/attachments/20190115/a2cbfe19/attachment.sig>

More information about the Pkg-nagios-devel mailing list