May 2006 - Xymon - Xymon mailman web

purple clients
by longina＠imada.sdu.dk 29 May '06

29 May '06

I have a group of clients which recently I started to reboot daily. Now, they never recover from the purple on cpu/disk/memory.. etc monitoring. Client processes run fine, but in clientdata.log, there are a lot of: --- 2006-05-29 13:32:43 hobbitd_client: Got message 12359 @@client#12359|1148902363.482265|130.225.128.99|leonora.imada .sdu.dk|linux 2006-05-29 13:32:43 2006-05-29 13:32:43 Worker process died with exit code 134, terminating --- Any ideas? regards Longina PS. It is _not_ a hostname problem! -- Longina Przybyszewska, system programmer Dept. of Math. & Comp. Sci. - IMADA University of Southern Denmark, Odense Campusvej 55,DK-5230 Odense M, Denmark tel: +45 6550 2359 - http://www.imada.sdu.dk email: longina at imada.sdu.dk --

2 1

service conn
by fscholz＠csc.com 29 May '06

29 May '06

Hi, I have some problems on solaris 9: The service "conn" is in status "red" service conn is not ok: host does not respond to ping remark: the hobbit-user has no sudo-rights. and: if I look at the conn status or other status messages, the image of hobbit graph is not shown. and: I get the following message, if I click on the "hobbit graph" Internet explorer cannot download.....eursun11&nostale&action=menu from eursun11. Internet explorer was not able to open this internet site. The requested site is either unavailable or cannot be found. Please try again later. Can someone help me? kind regards, Frauke Scholz CSC (Germany) Ltd.; MDS (Managed Desktop Services) Web & Middleware Engineering Wolfenbütteler Str. 86/Obergstr. 5 38102 Braunschweig Germany Phone: +49.5172.129279 or +49.531.224.1086 e-Mail: fscholz at csc.com Internet: http://www.de.csc.com Experience Results. Experience CSC. __________________________________________________ Please note that this e-mail, including any attachments, contains information that is subject to United States laws and regulations. The use or further dissemination of these materials or information therein may be prohibited by United States law. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2 1

554 SMTP synchronization error
by Dominique.Frise＠unil.ch 29 May '06

29 May '06

Hi all, Maybe this has been discussed already but I can't find any relevant info. All our smtp tests sporadically report similar error: ------------ yellow Wed May 17 14:37:21 2006 smtp NOT ok Service smtp on mailc is not OK : Unexpected service response 554 SMTP synchronization error.. Seconds: 0.00 ------------ How can we avoid this? Thanks. Dominique UNIL - University of Lausanne

3 4

[hobbit] Skinning BB
by Alun.Watson＠fp.co.nz 29 May '06

29 May '06

The Summary Screen is great for me but not quite what the helpdesk is looking for. I have modified the original shell script that Henrick sent me. I have included the hacked file and Erik Bosrup's overLIB javascript.It provides a small list of the error states a host has ie, Host error error1 error2 Quick visual assessment of when errors happened with popups that display the graph for that error (if there is one) using overlib_mini.js. To try it out copy ng.sh into your hobbit-cgi/ directory ... modify ng.sh to suit your environment BBSERVERROOT="/home/hobbit" HOBBITHTTP="http://something.blah/hobbit" HOBBITCGI="http://something.blah/hobbit-cgi" And put overlib_mini.js into the /hobbit/ dir of your webserver The popups seem to work in recent versions of IE and Firefox. It's not quite perfect but perhaps it conveys my idea more successfully. Regards, Alun -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Tuesday, 16 May 2006 10:32 To: hobbit at hswn.dk Subject: Re: [hobbit] Skinning BB On Tue, May 16, 2006 at 07:43:39AM +0200, Henrik Stoerner wrote: > On Tue, May 16, 2006 at 01:58:15PM +1200, Alun Watson wrote: > > Our helpdesk uses the All Non-green web page a lot and are only > > interested in the errors and have problems when they have to scroll > > up and down the page to figure out which column is which. > > OK, I understand now. But perhaps it is simpler to "play" with the > layout via a simple shell-script (not that I recommend doing shell > scripts for performance critical stuff - far from) to get the > design/layout right it is a useful prototype. Thinking about this a bit more, it occurred to me that the current "hobbit-statusreport" CGI could easily be tweaked to support this. If you grab the latest snapshot, build it and copy the web/hobbit-statusreport.cgi file to your ~hobbit/server/bin/ directory. Then create this wrapper in your Hobbit cgi-bin directory: #!/bin/sh . /usr/lib/hobbit/server/etc/hobbitcgi.cfg exec /usr/lib/hobbit/server/bin/hobbit-statusreport.cgi \ --filter="color=red,yellow" --all \ --heading="All non-green systems" \ --show-column \ --show-summary \ --link Running this CGI script will produce a text-only report of the current non-green statuses. The "--show-summary" option causes the report to have just a stripped-down summary of the current status, if you want the full status text just remove that option. Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

Darwin clients: empty memory graph
by Dominique.Frise＠unil.ch 28 May '06

28 May '06

Hi, With today's snapshot the memory graph is still empty :-( Memory/Used/Total/Percentage info is reported correctly (only one line for Physical) Same issue with Darwin 8.6.0 (OSX 10.4.6) or 7.9.0 (OSX 10.3.9) Dominique UNIL - University of Lausanne

2 2

NCV variable for custom RRD's
by ivan.verbeeck＠vmma.be 28 May '06

28 May '06

Hello all, I recently added a custom test to our hobbit setup that will use the NCV format for the rrd graph. The only problem that i noticed is the option to use wildcards in the NCV_test variable to define the "default" dataset type. When i specify all the datasets in the environment variable and set them to GAUGE (wich i need for my test), it all works fine, but if i use the "*:GAUGE" in this variable the rrd is generated with datasets of the "DERIVE" type. Anyone a idea what can be wrong? Kind regards, Ivan

4 4

log permissions..
by olivier＠qalpit.com 28 May '06

28 May '06

Hi, by default on my systems, /var/log/message is only readable by root, the hobbit client (running under hobbit) reported msgs with a green status : "Cannot open logfile /var/log/messages : Permission denied" even thow i have "log inspection" defined in hobbit-client.cfg could this be considered as a warning instead of a green status ? whether there is no log inspection or not ?? olivier

2 1

Problem with 'worst' conn method reporting
by EES2Y＠hscmail.mcc.virginia.edu 28 May '06

28 May '06

Doesn't look like this made its way into the current alfa code. (We must migrated to a new servers and this bit me again, so I thought I'd give it a bump). -Eric Schwimmer Network Engineer UVA HSCS Network Engineering > -----Original Message----- > From: Schwimmer, Eric E *HS > Sent: Friday, November 04, 2005 9:40 AM > To: hobbit at hswn.dk > Subject: Problem with 'worst' conn method reporting > > > Hi Henrik, > > We've had a problem with the 'worst' conn method for a while now, > and I've never got around to reporting or looking into it. Basically > what happens is that a host with multiple IP addresses and the 'worst' > conn method wont report any status changes (it will always be > green, even > if one or all of its ips are unpingable). > > I think I've fixed this, it was a pretty simple bug; on line > 1383 of bbtest-net.c, I changed 'countasdown = 0;' to > 'countasdown = 1;'. > I didn't really investigate the ramifications of what this > change might > have on the rest of the code, so let me know if I'm way off base. > (I know it did fix the worst issue, though, because 3 of our > multi-interface > sites with unpingable ifcs immediately went red). > > Regards, > -Eric Schwimmer > Network Engineer > UVA HSCS Network Engineering >

2 1

[hobbit] Need for a report
by Stewart_Larsen＠doh.state.fl.us 28 May '06

28 May '06

How will this handle situations where you have the same machine listed on different subpages? Will that machine show up twice in the totals? Or only once? -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Tuesday, May 23, 2006 4:50 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Need for a report On Tue, May 23, 2006 at 04:27:10PM -0400, PNIXON at ci.somerville.ma.us wrote: > Cleaned up the formatting and changed from grep -h red to grep -l "^red" > > -- > #!/bin/sh > BBVAR="/bb/bbvar" > > TOTAL=`ls $BBVAR/logs/*.conn | wc -l` > red=`grep -l "^red" $BBVAR/logs/*.conn | wc -l` > yellow=`grep -l "^yellow" $BBVAR/logs/*.conn | wc -l` > clear=`grep -l "^clear" $BBVAR/logs/*.conn | wc -l` > blue=`grep -l "^blue" $BBVAR/logs/*.conn | wc -l` > purple=`grep -l "^purple" $BBVAR/logs/*.conn | wc -l` > > echo "Total Connectivity: $TOTAL > Red Conn: $red > Yellow Conn: $yellow > Clear Conn: $clear > Disabled Conn: $blue > Purple Conn: $purple" This works fine for a BB installation, but not for Hobbit since Hobbit doesn't store the logfiles on disk (not in the default configuration, at least). So as Francesco mentioned, you should fetch the status with the hobbitdboard command. Something like this would do it: bb 127.0.0.1 "hobbitdboard color=red,yellow,purple,green test=conn fields=color" | sort | uniq -c On one of my systems this yields: 1416 green 68 purple 143 red Sounds like what the original poster wanted. Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 79502299) is spam: Spam: https://antispam.doh.ad.state.fl.us/canit/b.php?c=s&i=79502299&m=29de7a2 be3c3 Not spam: https://antispam.doh.ad.state.fl.us/canit/b.php?c=n&i=79502299&m=29de7a2 be3c3 Forget vote: https://antispam.doh.ad.state.fl.us/canit/b.php?c=f&i=79502299&m=29de7a2 be3c3 ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS

2 1

ALERTS time of day problem
by Mike.Rowell＠Rightmove.co.uk 28 May '06

28 May '06

Morning All (UK Time) I've got an issue with the TIME function in hobbit-alerts which is causing us a few problems. Hobbit has been running fine and we've starting making finer grained control on the alerts so that we don't get paged out of hours for stuff that we don't need to deal with. Below is the hobbit-alerts entries. The problem is that last night at 03:30am we were called out for an alert on the aq service which according to how the alert is setup should only be paging us between 0900 and 1700 weekdays. This is on 4.2PRE, we have newer snapshots running in test but I don't want to upgrade this platform unless I have to as it is running completely stable except for this TIME problem. Any ideas? Mike Rowell ALERTS------ PAGE=test MAIL=systems FORMAT=PLAIN TIME=W:0900:1800 COLOR=red,yellow STOP HOST=%^switches.* MAIL=systems COLOR=red,yellow REPEAT=1h FORMAT=PLAIN MAIL=pager SERVICE=cpu COLOR=RED FORMAT=SMS DURATION>15 REPEAT=1h TIME=*:0800:2200 STOP HOST=* MAIL=systems SERVICE=mrtg COLOR=red,yellow FORMAT=PLAIN STOP MAIL=systems SERVICE=repli,prtdiag FORMAT=PLAIN REPEAT=1h COLOR=red,yellow STOP MAIL=systems COLOR=red,yellow REPEAT=1h FORMAT=PLAIN MAIL=pager SERVICE=cpu COLOR=RED FORMAT=SMS DURATION>15 REPEAT=1h STOP MAIL=pager SERVICE=aq COLOR=RED FORMAT=SMS DURATION>5 REPEAT=1h TIME=W:0900:1700 STOP MAIL=pager COLOR=RED FORMAT=SMS DURATION>5 REPEAT=1h ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs service. ________________________________________________________________________

2 1