[Nagiosplug-help] How to verify if nagios was built withembperl?

[Ralph.Grothe at itdz-berlin.de]

Hi Tal,

no, my plugin shouldn't produce any other output than the one
line with state and check result.

e.g.

$ /usr/lib/nagios/plugins/check_sensor_temp.pl -H sensor_r04 -C
public
SENSOR OK - temp: T0=23.60 degC 
$ echo $?
0
$ /usr/lib/nagios/plugins/check_sensor_temp.pl -H sensor_r04 -C
public -w 23 -c 5:30
SENSOR WARNING - temp exceeded: T0=23.60 degC 
$ echo $?
1
$ /usr/lib/nagios/plugins/check_sensor_temp.pl -H sensor_r04 -C
public -w 17:20 -c 15:23
SENSOR CRITICAL - temp exceeded: T0=23.60 degC 
$ echo $?
2



I also explicitly close stderr right after any possible help
screen messages.

You are right that I ignored importing %ERROR from utils.pm.
But then, I found utils.pm to deliver only very limited
functionality
so that setting up own NAGIOS* hashes and omitting all that
Exporter overhead
seemed more sensible (don't forget the ineluctable MIB loading
overhead etc.
if one wants to avoid those nasty numeric OIDs).

As said, it only required me to get rid of the SIGDIE handler.
So I substituted die() with an own nagios_die() of exactly same
content.
After this modification it seemed to work.

Though the plugin may still contain a few bugs
and although it wasn't thus meant for publication,
you may find it attached to this mail 
(set your pager to 4 chars tabstop).

It really can only be useful to anyone who uses the same kind of
sensor device
and who has installed net-snmp as well as the SNMP module from
CPAN,
and merely as a proposal for something more serious.

Ralph


> -----Original Message-----
> From: nagiosplug-help-bounces at lists.sourceforge.net
> [mailto:nagiosplug-help-bounces at lists.sourceforge.net]On Behalf
Of Tal
> Cohen
> Sent: Monday, September 24, 2007 3:33 PM
> To: Grothe, Ralph; nagiosplug-help at lists.sourceforge.net
> Subject: Re: [Nagiosplug-help] How to verify if nagios was
built
> withembperl?
> 
> 
> Hi Ralph,
> 
> While I am no expert, here are some thoughts that I hope will 
> be helpful:
> 
> Are you getting any additional output when running this as a 
> Nagios check?
> >From my experience working with the EPN, you will normally get
a perl
> message about P1.PL when you encounter an unknown state
(usually this
> happens to me when I modify a check, but did not restart
Nagios). 
> 
> Also, I notice that you are using "exit 3" instead of 
> importing %ERRORS from
> utils.pm and using "exit $ERRORS{'UNKNOWN')". If I remember 
> how EPN work
> right, by using exit 3, you actually exit the EPN environment 
> (which is not
> what you want). By using the %ERRORS hash instead, you remain 
> within EPN.
> 
> Last, can you post the entire check to the group? We may be 
> able to identify
> the problem that way too.
> 
> Tal
> 
> 
> 
>      
> 
> -----Original Message-----
> From: nagiosplug-help-bounces at lists.sourceforge.net
> [mailto:nagiosplug-help-bounces at lists.sourceforge.net] On
Behalf Of
> Ralph.Grothe at itdz-berlin.de
> Sent: Monday, September 24, 2007 9:22 AM
> To: nagiosplug-help at lists.sourceforge.net
> Subject: [Nagiosplug-help] How to verify if nagios was built 
> with embperl?
> 
> Hello,
> 
> this is a follow-on to my posting to this list about
inexplicable
> UNKNOWN state determination
> by nagios of a custom plugin.
> 
> Unfortunately, no one seemed interested enough to reply.
> 
> However, meanwhile I think to have traced down the culprit.
> 
> It seems to be my convenience definition of a __DIE__ signal
> handler in my plugin.
> 
> I defined this vileness in my code
> 
> $SIG{__DIE__} = sub { chomp(my $out = shift);
>                       printf "%s - %s\n",
> $NAGIOS_SERVICESTATE{3}, $out;
>                       exit 3
>                     };
> 
> 
> as a sort of catch all abnomalies which I could catch as usual
by
> an or-ed die.
> 
> As shown in my last posting (see below)
> my plugin's output and exit code behaved absolutely as expected
> when run as nagios from the shell.
> 
> As soon as I comment the above sigdie handler out the plugin
> shows
> the green OK also in the web interface when run by nagios.
> 
> Since the %SIG hash is a package global 
> I suspect that my nagios binary was built with some embperl
> support
> which I wasn't aware of.
> (btw, no difference when I declare my sig handler as local
which
> should mask 
> SIG's symbol table entry)
> 
> I haven't built nagios from the sources but for ease of
> installation
> resorted to prebuilt RPMs.
> Unfortunately, in these RPMs I couldn't find any hint about the
> build options,
> nor some spec file.
> 
> So, how can I verify that my nagios binary indeed is precaching
> Perl plugins
> and executing them via embperl?
> 
> When I look at the shared libs there is a reference to some
> libperl
> which to me looks like I do run an embperl enabled nagios.
> 
> # rpm -q nagios
> nagios-2.9-1.el5
> 
> # uname -r
> 2.6.18-8.el5
>  
> # cat /etc/redhat-release 
> Red Hat Enterprise Linux Server release 5 (Tikanga)
> 
> # ldd /usr/sbin/nagios 
>         linux-gate.so.1 =>  (0x00631000)
>         libperl.so =>
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so
> (0x00110000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x008a7000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0x00708000)
>         libdl.so.2 => /lib/libdl.so.2 (0x004ac000)
>         libm.so.6 => /lib/libm.so.6 (0x00483000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x046f2000)
>         libutil.so.1 => /lib/libutil.so.1 (0x00df8000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x004b2000)
>         libc.so.6 => /lib/libc.so.6 (0x00344000)
>         /lib/ld-linux.so.2 (0x00327000)
> 
> 
> Regards
> 
> Ralph
> 
> > -----Original Message-----
> > From: nagiosplug-help-bounces at lists.sourceforge.net
> > [mailto:nagiosplug-help-bounces at lists.sourceforge.net]On
Behalf
> Of
> > Ralph.Grothe at itdz-berlin.de
> > Sent: Friday, September 21, 2007 7:30 PM
> > To: nagiosplug-help at lists.sourceforge.net
> > Subject: [Nagiosplug-help] Inexplicable UNKNOWN state of
custom
> > plugindisplayed in web interface
> > 
> > 
> > Hello,
> > 
> > I have a nasty bug that I cannot resolve.
> > 
> > I have written a Perl plugin that runs snmp checks against
> > environmental sensor devices
> > to poll the temprature at various spots in the data centre.
> > 
> > As far as I can see I have obeyed the prerequisites a plugin
> must
> > meet.
> > It outputs a single line with status and values
> > as well as the correct return code.
> > 
> > When I execute it from the shell as nagios user it behaves as
> > expected.
> > e.g.
> > 
> > $ /usr/lib/nagios/plugins/check_sensor_temp.pl -H sensor_r06
-C
> > public -w 17:27 -c 10:30
> > SENSOR OK - temp: T0=21.40 degC T1=24.50 degC 
> > $ echo $?
> > 0
> > 
> > The plugin's output is also correctly displayed as above in
the
> > web interface's status information field.
> > However, this is not true for the bg coloring (which is
orange)
> > and 
> > the text in the table field that displays the status of the
> last
> > check, 
> > where it reads UNKNOWN,
> > just as if nagios had received an exit code of 3
> > 
> > In the nagios log in the filesystem I can only see
appearances
> of
> > my nothing changing forced
> > external commands from reschedule check clicks via the web
> > interface,
> > like this (but nothing else):
> > 
> > [1190389354] EXTERNAL COMMAND:
> > SCHEDULE_FORCED_SVC_CHECK;sensor_r06;SRZ_Temp;1190389352
> > 
> > Trying to look at the event log from within the web interface
> > stalls my browser
> > because the log file is obviously too long as I get a lot of
> > check results for passive checks
> > from distributed servers.
> > Maybe a quicker log rotation scheme could alliviate, but I
find
> > event log CGI broken
> > if it hangs my browser.
> > 
> > Can anyone give me some hint why I get UNKNOWN states
> displayed,
> > and how I could try to debug this (maybe some strace on the
> > nagios scheduler?)
> > 
> > Regards
> > 
> > Ralph
> > 
> >
--------------------------------------------------------------
> > -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Nagiosplug-help mailing list
> > Nagiosplug-help at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagiosplug-help
> > ::: Please include plugins version (-v) and OS when reporting

> > any issue. 
> > ::: Messages without supporting info will risk being sent to
> /dev/null
> > 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nagiosplug-help mailing list
> Nagiosplug-help at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-help
> ::: Please include plugins version (-v) and OS when reporting 
> any issue. 
> ::: Messages without supporting info will risk being sent to
/dev/null
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Nagiosplug-help mailing list
> Nagiosplug-help at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-help
> ::: Please include plugins version (-v) and OS when reporting 
> any issue. 
> ::: Messages without supporting info will risk being sent to
/dev/null
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_sensor_temp.pl
Type: application/octet-stream
Size: 6502 bytes
Desc: check_sensor_temp.pl
URL: <https://www.monitoring-plugins.org/archive/help/attachments/20070924/ecb9c9f3/attachment.obj>