mon-devel — Discussions related to mon development

Re: [Mon-devel] Max size of Details for a monitor

[Marc H. <ma...@pr...>]

David Nolan wrote:

> [...]
> Ah, yes, I missed that we was talking about the client segfaulting, 
> not the server.  Indeed, upgrading Mon::Client should solve thep roblem.
>
> -David


Yes, You have right, I did some mistake when I backport this new version 
to the debian packaging system and mixed some old and new Mon::Client.

It's work now.

Thanks a lot for your help.


So if someone needs *Debian/Sarge* (testing) mon package, I put my 
backports here (the correct version) :

http://www.practeo.ch/debian/



Regards,

Marc Hauswirth

Re: [Mon-devel] Max size of Details for a monitor

[David N. <vit...@cm...>]

--On Thursday, August 12, 2004 11:37 AM -0400 Jim Trocki 
<tr...@tr...> wrote:

> On Thu, 12 Aug 2004, David Nolan wrote:
>
>> Are you sure you're using the mon 1.0.0 pre4 version?  I believe all of
>> the  'big output messages cause segfaults' problems are fixed in that
>> version.  0.99.2 definitely still has that problem.
>
> also, he needs to be sure he's using the latest Mon::Client perl module,
> which is mon-client-1.0.0pre2.tar.gz. his problem really does seem due to
> the regex stack size glitch various people have complained about before.
> it isn't really a bug in mon itself, it's a limitation of perl's regex
> code. i've been able to reproduce the problem before, and i found that
> increasing the mon process' stack size via "ulimit -s" prevents it from
> crashing.
>
>
>

Ah, yes, I missed that we was talking about the client segfaulting, not the 
server.  Indeed, upgrading Mon::Client should solve thep roblem.

-David

David Nolan                    <*>                    vit...@cm...
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!

Re: [Mon-devel] Max size of Details for a monitor

[Jim T. <tr...@tr...>]

On Thu, 12 Aug 2004, David Nolan wrote:

> Are you sure you're using the mon 1.0.0 pre4 version?  I believe all of the 
> 'big output messages cause segfaults' problems are fixed in that version. 
> 0.99.2 definitely still has that problem.

also, he needs to be sure he's using the latest Mon::Client perl module, which
is mon-client-1.0.0pre2.tar.gz. his problem really does seem due to the regex
stack size glitch various people have complained about before. it isn't really
a bug in mon itself, it's a limitation of perl's regex code. i've been able to
reproduce the problem before, and i found that increasing the mon process'
stack size via "ulimit -s" prevents it from crashing.

Re: [Mon-devel] Max size of Details for a monitor

[David N. <vit...@cm...>]

Are you sure you're using the mon 1.0.0 pre4 version?  I believe all of the 
'big output messages cause segfaults' problems are fixed in that version. 
0.99.2 definitely still has that problem.

-David

--On Thursday, August 12, 2004 4:23 PM +0200 Marc Hauswirth 
<ma...@pr...> wrote:

> Hello,
>
> I'm currently updating a small monitor script for checking
> router/switches interfaces.
>
> I would like to send a in the details all interfaces status.
>
> For 1-2 switchs this work correctly, but for bigger installation (20
> switches) this make a lot of details (~ 12 kBytes) and monshow make me a
> "Segmentation fault" when I want to display the operation status.
>
> mon is still running in background correctly.
>
> Did you have / know some limitation on the output details size?
>
> Tanks in advance
>
> I use Debian (Sarge) with perl 5.8.4 ,Mon 1.0.0 pre4
>
> Regards,
>
> Marc Hauswirth
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Mon-devel mailing list
> Mon...@li...
> https://lists.sourceforge.net/lists/listinfo/mon-devel
>



David Nolan                    <*>                    vit...@cm...
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-devel] Max size of Details for a monitor

[Marc H. <ma...@pr...>]

Hello,

I'm currently updating a small monitor script for checking 
router/switches interfaces.

I would like to send a in the details all interfaces status.

For 1-2 switchs this work correctly, but for bigger installation (20 
switches) this make a lot of details (~ 12 kBytes) and monshow make me a 
"Segmentation fault" when I want to display the operation status.

mon is still running in background correctly.

Did you have / know some limitation on the output details size?

Tanks in advance

I use Debian (Sarge) with perl 5.8.4 ,Mon 1.0.0 pre4

Regards,

Marc Hauswirth

[Mon-devel] mon-1.0.0pre4 available

[Jim T. <tr...@tr...>]

the latest pre-1.0.0 release is available from:

ftp://ftp.kernel.org/pub/software/admin/mon/devel/

1.0.0 is getting close now. in fact, we've never been closer.  out of
all the pre-1.0.0 releases, this has been the closest. the closeness of
this release to 1.0.0 surpasses all previous releases.

i welcome all feedback. in fact, you're welcome to join the development
mailing list if you'd like to participate in heated discussions about
bugs, features, and misfeatures. info about the list is found here:

    http://lists.sourceforge.net/mailman/listinfo/mon-devel


Changes between mon-1.0.0pre3 and mon-1.0.0pre4
Tue Aug  3 08:02:35 EDT 2004
-----------------------------------------------

-when allow_empty_group is not set and no host arguments
 to pass to a monitor, the interval wasn't being reset so
 it would spam the syslog with lots of "no host arguments"
 messages. this is fixed.

-in reset_timer, there was a chance that _timer could get
 set to a negative value, which is not right. fixed it.

-fixed the bug where lots of mon processes could accumulate if the
 exec of an alert failed. also fixed error handling of failed
 alerts.

-added "show failures only" button to mon.cgi to speed it up.
 by Ed Ravin <er...@pa...>

-small permissions fix to rpm spec file

-added MON_CFBASEDIR variable to monitor and alert
 environment, which is set to the value of "cfbasedir" in the
 config file.

-removed unfinished snmp trap handling stuff. it doesn't work at all,
 and it's misleading to people even though the man page says it doesn't
 work.

-added monitor_duration and monitor_running output to opstatus detail
 in monshow

[Mon-devel] Re: mon.cgi patch for "show failures only"

[Jim T. <tr...@tr...>]

On Mon, 12 Jul 2004, Ed Ravin wrote:

> I see that mon.cgi has been brought back into the fold - here's a
> patch that seems to have been overlooked - it adds a "show failures only"
> button to the menu.

thanks, i've applied this patch to the 1.0.0 branch.

please give pre3 a shot and let me know how it's working. i'm testing it
here and so far it seems quite good. the trap stuff is working much better.

RE: [Mon-devel] old/new monitor

[Peter W. (MO/EMW) <pet...@er...>]

oh... if there are any questions...

  I'm leaving for vacation now and will be 
  back in 4 weeks. Reading mail, about once a week or so...

 have a good time...

/Peter

[Mon-devel] old/new monitor

[Peter W. (MO/EMW) <pet...@er...>]

Here is my netsnmp.monitor...

NAME
    netsnmp.monitor - monitor disk usage, processes, system load and snmp
    status via SNMP

SYNOPSIS
    netsnmp.monitor [ --version ] [ --community=community ] [ --port=port ]
    [ --disk ] [ --load ] [ --proc ] [ --snmp ] host [...]

ARGUMENTS
    --version
        Prints netsnmp version and exits.

    --community=community
        SNMP community (default=public).

    --port=port
        SNMP port number (default=161).

    --disk (default)
        Check disk usage(enterprises.ucdavis.diskTable) on host(s).

    --load
        Check system load(enterprises.ucdavis.loadTable) on host(s).

    --proc
        Check processes(enterprises.ucdavis.procTable) on host(s).

    --snmp
        Check snmpd status(enterprises.ucdavis.snmperrs) on host(s).

    host [...]
        Space separated list of hosts to monitor.

DESCRIPTION
    netsnmp.monitor monitors disk usage, processes, system load and snmp
    status via the UCSD SNMP agent. It is designed to be used as a monitor
    for the mon package. If all of the ErrorFlag's
    (prErrorFlag.*,dskErrorFlag.*,laErrorFlag.*,snmperrErrorFlag.*) that
    corresponds to the arguments (--proc, --disk, --load, --snmp) are 0. 0
    is returned otherwise, it will return 1 and output the hostnames that
    failed and a description of what has failed.

EXAMPLES
    netsnmp.monitor -proc -disk -load -snmp adm eng

    Host: adm

    ErrMsg: /export/home/adm: less than 5% free (= 97%) Device:
    /dev/vx/dsk/DA-adm/vol-home Total: 11781824 Avail: 295715 Used: 10307929

    ErrMsg: No cron process running. Names: cron Min: 0 Max: 0 Count: 0
    ErrFix: 0

    Host: eng

    ErrMsg: /store: less than 50% free (= 85%) Device: /dev/dsk/c0t1d0s3
    Total: 2012390 Avail: 305878 Used: 1699805

    ErrMsg: 15 min Load Average too high (= 0.03) Load: 0.03 Config: 0.03

SEE ALSO
    *http://mon.sourceforge.net/* *http://www.netsnmp.org/*

AUTHOR
    Peter Wirdemo <pet...@er...>

COPYRIGHT
    Copyright (c) 1998 Peter Wirdemo. Sweden. All rights reserved. This
    program is free software; you can redistribute it and/or modify it under
    the same terms as Perl itself.

Re: [Mon-devel] process_event in mon-1-0-0pre1 branch

[David N. <vit...@cm...>]

--On Friday, July 09, 2004 8:58 AM -0700 Jim Trocki <tr...@tr...> 
wrote:

> On Fri, 9 Jul 2004, David Nolan wrote:
>
>> Out of curiousity, why did you decide to do this work in the 1.0 branch?
>> I  think significant changes like this should probably go into directly
>> into  Mon 1.1, especially since I'd like to see a 1.1-dev* release
>> "soon".
>
> because:
>
>     -it fixed major brokenness that people have reported
>     -it wasn't a ton of work
>     -it didn't add major features or change the behavior of anything
>      (other than fixing brokenness)
>     -it made the code easier to maintain
>


Ok, those reasons are perfectly reasonable.

> i'm trying to fix up this 1.0.0 branch so that it can be released in
> very good shape. after that happens i'll leave it go and do nothing
> more with it than fix bugs, and future work will be on the head branch.
> i think the 1.0.0 point is really close, and the only other changes to
> it i'm really looking to make is to incorporate mon.cgi, maybe pick a
> monitors or two from contrib, and touch up the docs.
>

Hmm, I should look at my copy of mon.cgi and figure out if any of our local 
patches are interesting.  I think the answer is yes, but only for Mon 1.1.

And I should do the same for my various monitor scripts.  I think there
are some that will be of general use.  (krb5, imap-ssl, powerware UPS, 
cisco router health monitoring, etc.)


> nothing in 1.0.0 should hold up a 1.1 release, really. after all, it's
> the "development" branch.
>

I haven't looked at these changes yet, but I'll probably try to integrate 
them over the weekend.

-David

David Nolan                    <*>                    vit...@cm...
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!

Re: [Mon-devel] process_event in mon-1-0-0pre1 branch

[Jim T. <tr...@tr...>]

On Fri, 9 Jul 2004, David Nolan wrote:

> Out of curiousity, why did you decide to do this work in the 1.0 branch?  I 
> think significant changes like this should probably go into directly into 
> Mon 1.1, especially since I'd like to see a 1.1-dev* release "soon".

because:

    -it fixed major brokenness that people have reported
    -it wasn't a ton of work
    -it didn't add major features or change the behavior of anything
     (other than fixing brokenness)
    -it made the code easier to maintain

i'm trying to fix up this 1.0.0 branch so that it can be released in
very good shape. after that happens i'll leave it go and do nothing
more with it than fix bugs, and future work will be on the head branch.
i think the 1.0.0 point is really close, and the only other changes to
it i'm really looking to make is to incorporate mon.cgi, maybe pick a
monitors or two from contrib, and touch up the docs.

nothing in 1.0.0 should hold up a 1.1 release, really. after all, it's
the "development" branch.

Re: [Mon-devel] process_event in mon-1-0-0pre1 branch

[David N. <vit...@cm...>]

--On Friday, July 09, 2004 6:58 AM -0700 Jim Trocki <tr...@tr...> 
wrote:

> david, you might want to have a look at these changes and judge their
> suitability for the head branch. i think they're probably suitable but
> i don't know how it would affect any changes you've made.

Out of curiousity, why did you decide to do this work in the 1.0 branch?  I 
think significant changes like this should probably go into directly into 
Mon 1.1, especially since I'd like to see a 1.1-dev* release "soon".

-David

David Nolan                    <*>                    vit...@cm...
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-devel] process_event in mon-1-0-0pre1 branch

[Jim T. <tr...@tr...>]

over the past few days i've made a change which eliminates a bunch of
redundant code between proc_cleanup, handle_trap, and handle_trap_timeout,
and as an effect has both simplified these routines and fixed a bunch of
bugs related to trap processing and alerts/upalerts and all associated
squelch knobs (alertevery, alertafter, etc.).

there is a new sub named "process_event" which is called by proc_cleanup,
handle_trap, and handle_trap_timeout. this sub handles all the gritty
details such as incrementing the counters, setting last_failure, calling
do_alert, among other things. process_event can be called in one of three
modes, "m" for monitor, "t" for trap, and "T" for traptimeout. this
triggers very small bits of code which vary for each of those types
of events.

in addition, i eliminated the code in handle_trap which looks at
$trap{"spc"}, so all of that $TRAP_COLDSTART, $TRAP_LINKDOWN, etc. stuff
is no more (it was a mess, anyway). the only status it uses is what is
found in $trap{"sta"}, and it uses that in the same way proc_cleanup uses
$?, the exit value of the monitor. this means that now traps are handled
in the same exact way as monitors, which is a very good thing, imho.

oh, and the traptimeout stuff is fixed, i.e. it works as the man page
says.

i've spent an hour or two testing a bunch of combinations of trap +
alert + upalert + alertafter/alertevery and monitor + that stuff, and
it all seems to work just fine. however, i haven't tested all possible
combinations, so i'm hoping others could givet this version a shot and
let me know if it works better for them.

david, you might want to have a look at these changes and judge their
suitability for the head branch. i think they're probably suitable but
i don't know how it would affect any changes you've made.

the version i'm talking about is checked into cvs under the mon-1-0-0pre1
branch, revision 1.4.2.9. it probably hasn't made its way to the anon
cvs mirror at sf.net, though. if anyone wants it immediately let me know
and i'll mail it to you.

Re: [Mon-devel] _last_checked?

[Jim T. <tr...@tr...>]

On Tue, 6 Jul 2004, David Nolan wrote:

> So, changing proc_cleanup() to set _next_check when a monitor script exits 
> will only result in the timestamp passed to Mon clients being when the 
> script exited instead of when it was started.  But when it exited is 
> actually already available as either _last_success or _last_failure.  But 
> having _last_check be when the script was started might be interesting for 
> purposes of calculating how long mon scripts are taking to run.

> I'd lean towards deleting the line from proc_cleanup.

better yet, just make that line be this instead:

        $sref->{"_monitor_duration"} = $tmnow - $sref->{"_last_check"};

and make this change in client_write_opstatus:

    $buf .= " interval=$sref->{interval}" .
            " monitor_duration=$sref->{_monitor_duration}"
        if ($sref->{"interval"});

then you can get that "how long did it run" info if you want. afaik
nobody has requested that feature, but i can see how it could be useful
if you're trying to tune your config or if you are debugging something
monitor-related.

Re: [Mon-devel] _last_checked?

[Jim T. <tr...@tr...>]

On Tue, 6 Jul 2004, Tim Klein wrote:

> Subroutine proc_cleanup() contains a reference to _last_checked .
> Shouldn't that be _last_check instead?  I can't find any other
> reference to _last_checked in the mon code.

yeah that's a bug. i fixed it in my mon-1-0-0pre1 sandbox, and i'll
check it in later.

Re: [Mon-devel] _last_checked?

[David N. <vit...@cm...>]

--On Tuesday, July 06, 2004 8:55 AM -0500 Tim Klein 
<tkp...@ti...> wrote:

> Subroutine proc_cleanup() contains a reference to _last_checked .
> Shouldn't that be _last_check instead?  I can't find any other
> reference to _last_checked in the mon code.

At first glance, that certainly looks like a bug.

However its not completely clear if the typo should be fixed or the
line deleted.

run_monitor() sets _last_check and _next_check
proc_cleanup() sets _last_failure or _last_success

_last_check is never used internal to Mon, except to set _next_check

So, changing proc_cleanup() to set _next_check when a monitor script exits 
will only result in the timestamp passed to Mon clients being when the 
script exited instead of when it was started.  But when it exited is 
actually already available as either _last_success or _last_failure.  But 
having _last_check be when the script was started might be interesting for 
purposes of calculating how long mon scripts are taking to run.

I'd lean towards deleting the line from proc_cleanup.

Jim?

-David

David Nolan                    <*>                    vit...@cm...
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-devel] _last_checked?

[Tim K. <tkp...@ti...>]

Subroutine proc_cleanup() contains a reference to _last_checked .
Shouldn't that be _last_check instead?  I can't find any other
reference to _last_checked in the mon code.

Tim

Re: [Mon-devel] Re: Best way to contribute

[David N. <vit...@cm...>]

--On Thursday, July 01, 2004 8:59 AM -0500 Tim Klein 
<tkp...@ti...> wrote:

>
> I don't know about any other site-specific mods you may have made,
> but the one you describe above certainly sounds to be of general
> interest.

Ok.  In the interest of figuring out our solution is reasonable for other 
people I'll give some more details.

The config file contains arbitrary variables, that can either apply to 
specific hostgroups, services, hostgroup & service pairs, or be default 
values.  In certain cases we even can provide per-machine settings. 
Examples of settings we use this for are: snmp community strings, database 
users & passwords, username & password for testing kerberos servers, paths 
to keytab files, etc.


Here's an example of the way it works.  The mon script has a block of code 
like this:

my %communities;
my $group=$ENV{MON_GROUP};
my $service=$ENV{MON_SERVICE};
my $cf;
$community ||= $opt{'community'};
if ($cf = new IO::File "</home/mon/etc/monitor-auth.cf") {
  while (<$cf>) {
    chomp;
    if (/^(\S+):readcommunity\s*=\s*(\S+)$/) {
      $communities{$1}=$2;
    }
  }
  $community ||= $communities{"$group:$service"};
  $community ||= $communities{"$group:*"};
  $community ||= $communities{"*:$service"};
  $community ||= $communities{"*:*"};

}

$community ||= 'public';


Then monitor-auth.cf contains entries like this:
hostgroup-x:*:readcommunity=foobar
hostgroup-y:*:readcommunity=qux
*:service-x:readcommunity=baz
hostgroup-y:service-x:readcommunity=abc
*:*:readcommunity=asdf


-David

David Nolan                    <*>                    vit...@cm...
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!

Re: [Mon-devel] Re: Best way to contribute

[Tim K. <tkp...@ti...>]

>The only issue is I'll have to figure out is what to do about 
>ripping out some of our local code.  We've updated every monitor 
>script that has some piece of 'secret' configuration data 
>(passwords, snmp strings, etc) to use a common config file to get 
>that data.  That way we don't have to put the passwords into the 
>config file (i.e. in the database, and more importantly visible 
>through the web interface) or the monitor script itself (which would 
>put the passwords into CVS).
>
>While I think those changes are useful, I'm not sure they're 
>interesting to anyone else.
>
>-David

David,

I don't know about any other site-specific mods you may have made,
but the one you describe above certainly sounds to be of general
interest.

Tim

Re: [Mon-devel] Re: Best way to contribute

[David N. <vit...@cm...>]

--On Tuesday, June 29, 2004 8:21 AM -0700 Jim Trocki 
<tr...@tr...> wrote:

>> To address the original question, I think we should take advantage of the
>> sourceforge CVS features and move the contrib stuff into sourceforge.
>> Then  we can grant individuals the ability to commit new versions there.
>> Thoughts?
>>
>> -David
>
> yeah, making a "contrib" module in cvs might be ok for the sake of it,
> but some of the more substantial items should be moved into the main mon
> distribution. i've already done this for snmpvar.monitor, and mon.cgi
> should also go in there. i don't recall much activity from the people
> who've contributed the rest of them, however.
>
>

We could also grant additional people cvs access to just the mon.d 
directory.

At some point soon I'll go through my set of monitor scripts and figure out 
which ones are interesting enough to add to CVS.

The only issue is I'll have to figure out is what to do about ripping out 
some of our local code.  We've updated every monitor script that has some 
piece of 'secret' configuration data (passwords, snmp strings, etc) to use 
a common config file to get that data.  That way we don't have to put the 
passwords into the config file (i.e. in the database, and more importantly 
visible through the web interface) or the monitor script itself (which 
would put the passwords into CVS).

While I think those changes are useful, I'm not sure they're interesting to 
anyone else.


-David


David Nolan                    <*>                    vit...@cm...
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-devel] Re: Best way to contribute

[Jim T. <tr...@tr...>]

> To address the original question, I think we should take advantage of the
> sourceforge CVS features and move the contrib stuff into sourceforge.  Then 
> we can grant individuals the ability to commit new versions there. 
> Thoughts?
>  
> -David

yeah, making a "contrib" module in cvs might be ok for the sake of it,
but some of the more substantial items should be moved into the main mon
distribution. i've already done this for snmpvar.monitor, and mon.cgi
should also go in there. i don't recall much activity from the people
who've contributed the rest of them, however.

[Mon-devel] Re: Best way to contribute

[David N. <vit...@cm...>]

--On Tuesday, June 29, 2004 5:26 AM -0700 Jim Trocki 
<tr...@tr...> wrote:

> On Tue, 29 Jun 2004, Peter Wirdemo (MO/EMW) wrote:
>
>> Hello all!
>>
>> What is the best way to contribute, now when mon is moving over to
>> sourceforge. My intreset in contributing is most in monitors, not so
>> much in mon itself.....
>
> i've made the "mon...@li..." mailing list for this
> purpose:
>
>     http://lists.sourceforge.net/mailman/listinfo/mon-devel
>
> (it'll take a little bit for it to show up)
>


Oh good, you did it.  Thanks.  I assume you've subscribed, so I won't cc 
you on this response.  :)

To address the original question, I think we should take advantage of the
sourceforge CVS features and move the contrib stuff into sourceforge.  Then 
we can grant individuals the ability to commit new versions there. 
Thoughts?

-David


David Nolan                    <*>                    vit...@cm...
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!