#204 Uninitialized value warning in check_ifoperstatus

Reuben Farrelly

I've been seeing this error for the last few weeks with
this plugin. This is the message returned by the
plugin when invoked via Nagios:

**ePN /usr/lib/nagios/plugins/check_ifoperstatus: "Use
of uninitialized value in numeric gt (>) at (eval 3257)
line 359".

Nagios displays an 'orange' status for this check.

line 359 looks like this:

unless ($snmpkey > 0 || defined $ifdescr){

When the command is executed manually, it looks like this:

[root@tornado plugins]#
/usr/lib/nagios/plugins/check_ifoperstatus -H -C snmpaccess -d ATM0
OK: Interface ATM0 (index 1) is up.[root@tornado plugins]#

(I wonder if a missing CR at the end is a bad thing..)


  • Subhendu Ghosh
    Subhendu Ghosh

    • assigned_to: nobody --> sghosh
  • Subhendu Ghosh
    Subhendu Ghosh

    Logged In: YES

    This is strange. snmpkey is initialized to 0 and you are
    using -d so snmpkey should remain at 0.

    Which version of nagios and plugin?

    How long has Nagios with ePN been running?

  • Logged In: YES

    Using both -CVS of Nagios and -CVS of nagiosplug...

    The config on this has not changed for many months.. Is it
    worth me disabling the ePN to test?

  • Logged In: YES

    Disabled --enable-embedded-perl with Nagios and the error
    has gone and all looks OK. Shall I close this and re-open a
    bug with Nagios instead or is this possibly just a bad
    interaction between the plugin and embedded perl?

  • Subhendu Ghosh
    Subhendu Ghosh

    Logged In: YES

    No - leave this open. Need to check what ePN changes have
    happened to cause this.

  • Logged In: YES

    Dear Folks,

    The problem is that the plugin does _not_ work with embedded
    Perl Nagios (ePN).

    ePN requires that plugins be written with more care than
    those designed to be run by a shell (why ? some features
    such as <DATA> handles do not work; and, in general,
    variables and their values persist from the last run, so
    their is more opportunity for things to go wrong. Also, ePN
    runs all code under the 'strict' pragma, regardless of
    whether there is a 'use strict' in the plugin. This leads to
    some plugins failing to run under ePN).

    As far as ePN changes go, there have been quite a lot of
    changes in the 2.x code base, none related to how the plugin
    is compiled or run (the changes have been attempts to deal
    with memory leaks related to the threading changes in Nag
    2.x and threaded Perls)

    None of my 55 Perl plugins have malfunctioned (except one
    that uses the Expect module. This is also a problem with
    ePN. Plugins that tie or re-open stdout are not going to
    play well with ePN because it ties stdout to a scalar so
    that the plugin output can be captured) during this time.

    My conclusion is

    1 this is not an ePN problem - so this is the appropriate
    support venue

    2 the problem is with the plugin text not cooperating with
    the use strict compilation environment in ePN. The plugin
    should be patched so that it runs under ePN.

    FWIW, the best way to do this is run it under the ePN
    simulator (contrib/mini_epn.c if this has been updated to
    correspond to the CVS .. Call me otherwise) with the
    /contrib copy of p1.pl edited to
    log to suitable file (DEBUG_LOG_PATH) and the DEBUG_LEVEL
    set to PLUGIN_DUMP.

    This should nail where the problem is.

    I have up to date versions of the plugin validation tools if
    anyone wants them (tools to check if plugins play nicely
    with ePN).