mon-devel Mailing List for mon (Page 8)
Brought to you by:
trockij
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(27) |
Mar
|
Apr
(9) |
May
(11) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(15) |
2006 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(14) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(4) |
Dec
(8) |
2008 |
Jan
(6) |
Feb
(4) |
Mar
(7) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2009 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(7) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Marc H. <ma...@pr...> - 2004-08-12 16:03:11
|
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 |
From: David N. <vit...@cm...> - 2004-08-12 15:44:42
|
--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! |
From: Jim T. <tr...@tr...> - 2004-08-12 15:37:17
|
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. |
From: David N. <vit...@cm...> - 2004-08-12 15:10:26
|
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! |
From: Marc H. <ma...@pr...> - 2004-08-12 14:23:37
|
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 |
From: Jim T. <tr...@tr...> - 2004-08-03 16:24:24
|
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 |
From: Jim T. <tr...@tr...> - 2004-07-12 18:51:51
|
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. |
From: Peter W. (MO/EMW) <pet...@er...> - 2004-07-09 16:56:10
|
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 |
From: Peter W. (MO/EMW) <pet...@er...> - 2004-07-09 16:49:09
|
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. |
From: David N. <vit...@cm...> - 2004-07-09 16:36:34
|
--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! |
From: Jim T. <tr...@tr...> - 2004-07-09 15:59:05
|
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. |
From: David N. <vit...@cm...> - 2004-07-09 15:29:37
|
--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! |
From: Jim T. <tr...@tr...> - 2004-07-09 13:58:44
|
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. |
From: Jim T. <tr...@tr...> - 2004-07-06 15:21:47
|
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. |
From: Jim T. <tr...@tr...> - 2004-07-06 14:48:06
|
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. |
From: David N. <vit...@cm...> - 2004-07-06 14:15:46
|
--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! |
From: Tim K. <tkp...@ti...> - 2004-07-06 13:59:58
|
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 |
From: David N. <vit...@cm...> - 2004-07-01 15:44:02
|
--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! |
From: Tim K. <tkp...@ti...> - 2004-07-01 14:00:13
|
>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 |
From: David N. <vit...@cm...> - 2004-06-29 15:38:09
|
--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! |
From: Jim T. <tr...@tr...> - 2004-06-29 15:22:07
|
> 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. |
From: David N. <vit...@cm...> - 2004-06-29 13:46:58
|
--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! |