headers
Hugh Caley | 14 Jan 2006 00:59
Favicon

SNMP Monitor Problems after RH 9 Upgrade

I just moved from RH 8 to 9 on my mon server, and I'm getting the 
following errors with the monitors that use SNMP:

[root <at> emilia mon.d]# ./foundry-chassis.monitor bigiron1
Can't load

'/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/NetSNMP/default_store/default_store.so' 
for module NetSNMP::default_store: libelf.so.0: cannot open shared 
object file: No such file or directory at 
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
 at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm line 16
Compilation failed in require at 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm line 16.
BEGIN failed--compilation aborted at 
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm line 16.
Compilation failed in require at ./foundry-chassis.monitor line 28.
BEGIN failed--compilation aborted at ./foundry-chassis.monitor line 28.

silkworm.monitor has the same errors.  Anyone seen this before?

Hugh

--

-- 
Hugh Caley | Unix Systems Administrator | CIS
AFFYMETRIX, INC. | 6550 Vallejo St. Ste 100 | Emeryville, CA 94608
Tel: 510-428-8537 | Hugh_Caley <at> affymetrix.com
Permalink | Reply | 1 comment |
headers
Hugh Caley | 14 Jan 2006 02:33
Favicon

Re: SNMP Monitor Problems after RH 9 Upgrade

Never mind, I figured it out.  I made a symlink for libelf.so.0 to 
libelf.so.1, and I deleted a version of SNMP.so from
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/SNMP and it 
works again.

Hugh

Hugh Caley wrote:

> I just moved from RH 8 to 9 on my mon server, and I'm getting the 
> following errors with the monitors that use SNMP:
>
> [root <at> emilia mon.d]# ./foundry-chassis.monitor bigiron1
> Can't load 
>
'/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/NetSNMP/default_store/default_store.so' 
> for module NetSNMP::default_store: libelf.so.0: cannot open shared 
> object file: No such file or directory at 
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
> at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm 
> line 16
> Compilation failed in require at 
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm line 16.
> BEGIN failed--compilation aborted at 
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/SNMP.pm line 16.
> Compilation failed in require at ./foundry-chassis.monitor line 28.
> BEGIN failed--compilation aborted at ./foundry-chassis.monitor line 28.
>
> silkworm.monitor has the same errors.  Anyone seen this before?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Landers | 27 Jan 2006 20:54

Monitor works from the command-line but not from mon

I have a tacacs+ monitoring script that successfully detects failures
when run from the command-line but not from within mon.  I'm at a loss
to troubleshoot this one and am hoping the list can help.  It seems to
be printing the failure in the proper format and setting the exit code
properly, but mon never sees the service as down.

-bash-2.05b$  ./tacacs.monitor username password key server1 server2
server1
    server1: Attempt timed out!

-bash-2.05b$ echo $?
1

watch acs_servers
    service tacacs
        description Make sure TACACS is working
        interval 15m
        monitor /usr/local/mon/tacacs.monitor username password key
        period wd {Sun-Sat}
            alert mail.alert netadmins <at> example.com
            upalert mail.alert -S "Service is back up" netadmins <at> example.com
            alertevery 15m

Thanks in advance,
Brian

--
Brian Landers
Senior Network Engineer
Sapient IT Infrastructure
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Nolan | 27 Jan 2006 21:08
Picon
Favicon

Re: Monitor works from the command-line but not from mon


--On Friday, January 27, 2006 14:54:40 -0500 Brian Landers 
<brian <at> bluecoat93.org> wrote:

> I have a tacacs+ monitoring script that successfully detects failures
> when run from the command-line but not from within mon.  I'm at a loss
> to troubleshoot this one and am hoping the list can help.  It seems to
> be printing the failure in the proper format and setting the exit code
> properly, but mon never sees the service as down.
>
> -bash-2.05b$  ./tacacs.monitor username password key server1 server2
> server1
>     server1: Attempt timed out!
>
> -bash-2.05b$ echo $?
> 1
>

The most common source of problems on this sort is a diffence in the 
environment of your shell vs Mon.  Typically when the script calls an 
external program without specifying the full path, but other possibilities 
exist.

When mon runs the test what output does it see, and what exit code?

You might try adding debugging code to output the contents of %ENV 
(assuming this is perl), and some debug statements tracing your scripts 
execution.  (i.e. "testing server XXX", "server XXX failed", "returning 
failure code (1)", etc...)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ed Ravin | 27 Jan 2006 21:18
Picon
Favicon

Re: Monitor works from the command-line but not from mon

On Fri, Jan 27, 2006 at 02:54:40PM -0500, Brian Landers wrote:
> I have a tacacs+ monitoring script that successfully detects failures
> when run from the command-line but not from within mon.  I'm at a loss
> to troubleshoot this one and am hoping the list can help.  It seems to
> be printing the failure in the proper format and setting the exit code
> properly, but mon never sees the service as down.

You've reset Mon and the service shows up in the listing, right?  Just
checking, sometimes folks skip that step.

Are you using mon.cgi?  Drill down into the list for the tacacs+ test.
You should see a list of things like "last time monitor was run" and
other timestampes related to when the monitor was run and what the results
were.  Is Mon even running the monitor in the first place?

> -bash-2.05b$  ./tacacs.monitor username password key server1 server2
> server1
>     server1: Attempt timed out!
> 
> -bash-2.05b$ echo $?
> 1

That looks right.

> watch acs_servers
>     service tacacs
>         description Make sure TACACS is working
>         interval 15m
>         monitor /usr/local/mon/tacacs.monitor username password key
>         period wd {Sun-Sat}
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kishore Jalleda | 27 Jan 2006 21:25
Picon

Re: Monitor works from the command-line but not from mon

I agree with David's point,I am not a Mon pro but what I would suggest is specifying only the alert part without the full path like this, and also as he suggested check to see the output and the status codes when mon starts....

alertdir = /usr/local/mon/alert.d
mondir = /usr/local/mon/mon.d ( this is where your tacacs.monitor script is )
watch acs_servers
   service tacacs
       description Make sure TACACS is working
       interval 15m
       monitor tacacs.monitor username password key
       period wd {Sun-Sat}
           alert mail.alert netadmins <at> example.com
           upalert mail.alert -S "Service is back up" netadmins <at> example.com
           alertevery 15m
 
Kishore Jalleda

On 1/27/06, David Nolan <vitroth+ <at> cmu.edu> wrote:
>
>
> --On Friday, January 27, 2006 14:54:40 -0500 Brian Landers
> < brian <at> bluecoat93.org> wrote:
>
> > I have a tacacs+ monitoring script that successfully detects failures
> > when run from the command-line but not from within mon.  I'm at a loss
> > to troubleshoot this one and am hoping the list can help.  It seems to
> > be printing the failure in the proper format and setting the exit code
> > properly, but mon never sees the service as down.
> >
> > -bash-2.05b$  ./tacacs.monitor username password key server1 server2
> > server1
> >     server1: Attempt timed out!
> >
> > -bash-2.05b$ echo $?
> > 1
> >
>
> The most common source of problems on this sort is a diffence in the
> environment of your shell vs Mon.  Typically when the script calls an
> external program without specifying the full path, but other possibilities
> exist.
>
> When mon runs the test what output does it see, and what exit code?
>
> You might try adding debugging code to output the contents of %ENV
> (assuming this is perl), and some debug statements tracing your scripts
> execution.  (i.e. "testing server XXX", "server XXX failed", "returning
> failure code (1)", etc...)
>
> -David
>
> David Nolan                    <*>                     vitroth+ <at> cmu.edu
> curses: May you be forced to grep the termcap of an unclean yacc while
>      a herd of rogue emacs fsck your troff and vgrind your pathalias!
>
> _______________________________________________
> mon mailing list
> mon <at> linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/mon
>
 
_______________________________________________
mon mailing list
mon <at> linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
Permalink | Reply | 2 comments |
headers
David Nolan | 27 Jan 2006 21:31
Picon
Favicon

Re: Monitor works from the command-line but not from mon


--On Friday, January 27, 2006 15:25:26 -0500 Kishore Jalleda 
<kjalleda <at> gmail.com> wrote:

> I agree with David's point,I am not a Mon pro but what I would suggest is
> specifying only the alert part without the full path like this, and also
> as he suggested check to see the output and the status codes when mon
> starts....

Oh!

I hadn't even noticed that...   thats exactly the problem.  The monitor 
option should have only the name of the script in the monitor directory, 
not the full path.

Good eyes... :)

-David

David Nolan                    <*>                    vitroth+ <at> cmu.edu
curses: May you be forced to grep the termcap of an unclean yacc while
      a herd of rogue emacs fsck your troff and vgrind your pathalias!
Permalink | Reply | 1 comment |
headers
Brian Landers | 27 Jan 2006 22:09

TACACS+/ACS monitoring script

A couple of people have emailed me asking for the TACACS+/ACS
monitoring script I mentioned.  Here's the link to it.  It requires
the Perl module Auth::TacacsPlus from CPAN.

http://www.packetslave.com/code/tacacs.monitor.txt

Cheers,
Brian

--
Brian Landers
Senior Network Engineer
Sapient IT Infrastructure
Permalink | Reply | 0 comments |
headers
Nate Reed | 27 Jan 2006 22:17

mysql monitor fails: _ListTables deprecated

I installed and configured mon 0.99.2 and I noticed the following errors in 
the mysql monitor:

Jan 27 15:09:57 node1 mon[3960]: failure for cluster mysql 1138396197 
_ListTables is deprecated, use $dbh->tables() 
at /usr/lib/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/DBD/mysql.pm 
line 280.
Jan 27 15:09:57 node1 mon[3960]: calling alert mail.alert for cluster/mysql 
(/usr/lib64/mon/alert.d/mail.alert,nreed <at> awarix.com) _ListTables is 
deprecated, use $dbh->tables() 
at /usr/lib/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi/DBD/mysql.pm 
line 280.

Yet the release notes for Jun 2004 indicate this has been fixed:

 -mysql.monitor - fix for deprecation of _ListTables
 by Aled Treharne 

What's wrong?
Permalink | Reply | 1 comment |
headers
Brian Landers | 27 Jan 2006 22:07

Re: Monitor works from the command-line but not from mon

David Nolan said:

> I hadn't even noticed that... thats exactly the problem. The monitor option should have
> only the name of the script in the monitor directory, not the full path.

Yes indeed!  That resolved it.  We have the system monitors in
/usr/lib/mon/mon.d and our homegrown monitors checked out from SVN in
/usr/local/mon.  I added /usr/local/mon to the end of mondir and
changed the monitor spec to just the name.  Works like a champ!

Thanks all!
*B
Permalink | Reply | 0 comments |

Gmane