- Xymon - Xymon mailman web

noconn and Enable/disable CGI
by Dominique.Frise＠unil.ch 09 Aug '06

09 Aug '06

Hi, We have hosts split across multiple pages and for service or OS grouping, same hosts can appear on several pages. Our admins are complaining that if they are viewing a page were there are hosts with the "noconn" tag, these do not appear in the Enable/disable hosts selection. It seems that the "Acknowledege Alert" CGI with the --no-pin flag has the same kind of behaviour. Is there a -hidden- configuration solution for this? Dominique UNIL - University of Lausanne

3 9

Hobbitd_client test???
by Vernon.Everett＠dpi.wa.gov.au 09 Aug '06

09 Aug '06

Hi all More problems. :-( What is causing this problem, and how can I fix it. A new test suddenly appeared called hobbitd_client and it reported red on my hobbit server line. In clientdata.log I found this. --- snip --- 2006-08-09 09:47:15 Want msg 1138, startpos 608983, fillpos 629463, endpos -1, usedbytes=20480, bufleft=7763240 2006-08-09 09:47:15 hobbitd_client: Got message 1138 @@client#1138|1155088035.931883|127.0.0.1|shire|sunos|sunos 2006-08-09 09:47:15 startpos 642855, fillpos 642855, endpos -1 2006-08-09 09:47:15 2006-08-09 09:47:17 Worker process died with exit code 134, terminating 2006-08-09 09:47:17 Want msg 1, startpos 0, fillpos 0, endpos -1, usedbytes=0, bufleft=8392703 --- snip --- Any ideas? Regards Vernon

2 1

[hobbit] Note: Hobbit 4.2 release planned for Thursday Aug. 10.
by brodie＠mcw.edu 09 Aug '06

09 Aug '06

I will try to squeeze in time to test the "duplicate data" error in my RRD data. I do not yet have the latest snapshot + all-in-1... (how to we get the snapshot and all in 1?) --------------------------------------------------------- Kent C. Brodie - brodie at phys.mcw.edu Department of Physiology Medical College of Wisconsin (414) 456-8590 -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Tuesday, August 08, 2006 4:22 PM To: hobbit at hswn.dk Subject: [hobbit] Note: Hobbit 4.2 release planned for Thursday Aug. 10. Unless some major showstopper arrives within 24 hours, the 4.2 release will be available Thursday morning around 8 AM UTC. In other words, this is your last chance to report bugs that must be fixed before the final release. The "ps" handling bugs should all be fixed now in the latest snapshot and all-in-one patch (dated 2006-08-08 21:13 UTC). A list of the bugs that have been fixed during the RC testing can be found at the beta-patches page, http://www.hswn.dk/hobbitsw/betapatches/ I would like to express my sincere admiration and thanks to the people who have taken the trouble of testing Hobbit for this release; your input and help in troubleshooting the problems has really made this release a lot better than it was 4 weeks ago. Thanks, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

2 1

[hobbit] Thank you Henrik, clientupdate, logfetch, ps parsing
by David.Gore＠VerizonBusiness.com 08 Aug '06

08 Aug '06

Henrik, Thank you for all the hard work! I can not tell you how better it is to proactive instead of reactive thanks to Hobbit. Thank you for working with me on clientupdate, logfetch and the ps parsing bugs. I am planning on taking a big rest from snapshots with the new release and will concentrate on installing it on our numerous hosts. The clientupdate feature really is nice, a very powerful tool! ~David

1 0

I found my RRD weirdness with illegal updates (2 in same time) - probable idea or fix required to resolve
by brodie＠mcw.edu 08 Aug '06

08 Aug '06

Hi everyone. Some time ago, I asked about this: 2006-08-02 12:24:50 RRD error updating /home/hobbit/data/rrd/taylor.brc.mcw.edu/disk,root.rrd from 141.106.224.178: illegal attempt to update using time 1154539490 when last update time is 1154539490 (minimum one second step) Nobody had anything useful for me, because there could be tons of causes.... However, just now, I finally figured it out. Seems that the previous sysadmin decided to create a home directory for "root" to store all his files (tarballs, etc). It was mounted as simply, "/root". This is all perfectly valid, *UNTIL* we get to rrd and disk usage. Within the realm of hobbit and rrd, the actual root file system ("/") is stored in rrd as /home/hobbit/data/rrd/taylor.brc.mcw.edu/disk,root.rrd When the client system had both "/" and "/root", this had the nifty side effect of causing hobbit'd RRD environment to become confused-- that's why I had an extra graph that had a placeholder, but nothing was being generated! That's because I had 17 mounted filesystems, which (divided by 4) is 5 graphs. But the 5th graph never showed up, and I looked carefully and figured out it was "/root" that wasn't being graphed. That's when the lightbulb went off. Two file systems "/" and "/root" were being called the same thing in terms of rrd: "root". Oooops. SO.......... While I decided to simply move the "/root" crud to somethere that made more sense... I have apparently tripped upon something that hobbit+rrd isn't prepared to deal with, which is a file system called "/root". While I think this would be rare, it's possible. Not sure how it would be handled? Maybe call the "/" file system "root~" or include some other special character in the name? --------------------------------------------------------- Kent C. Brodie - brodie at phys.mcw.edu Department of Physiology Medical College of Wisconsin (414) 456-8590

2 1

Bbgen problems with latest snapshot
by fduranti＠q8.it 08 Aug '06

08 Aug '06

I've a problem with bbgen and pageset... I'm creating a new set of pages with the bbgen pageset feature of hobbit and I've found I've a problem with the default host tag with bbgen. I've a set of pages definition in the bb-hosts file for bbgen: beapage PServers Prod Servers beagroup Physical Servers beagroup Virtual Servers beapage PDomains Prod Domains beagroup WLI Domains beagroup WLS Internal Domains beagroup WLS Internet Domains beapage PDatabase Prod DB Servers before defining the host i want to go to those pageset i define the default and then the host: 0.0.0.0 .default. # BEA:PDomains,3 group-compress WLS Internet Web Sites 0.0.0.0 Q8 # noconn nodisp beastat 0.0.0.0 Q8.Q8Server # noconn beaping BEA:PDomains,3 0.0.0.0 Q8.Q8Server_1 # noconn beaping 0.0.0.0 Q8.Q8Server_2 # noconn beaping 0.0.0.0 Q8Oils # noconn nodisp beastat Now the Q8.Q8Server is going to the pageset in the group number 3 (I've added the definition in the host to see if it work)... all the other ones don't get the .default. tag .... Another problem with pageset is that i cannot create .rss file in the pagesets... someone know if I'm doing something wrong or if it's normal or a bug? To create the pageset i've a script I call from the hobbitlaunch with 2 parameters that will result in this output: BBWEB="/hobbit/BEA"; BBMENUSKIN="$BBWEB/menu"; exec bbgen --pageset=bea --report=bbgen-bea --nopurple --nstab=BEA/nstab.html $BBGENOPTS $BBHOME/www/BEA my BBGENOPTS is BBGENOPTS="--recentgifs --subpagecolumns=2 --nopropred=msgs,vmio --pagetext-headings --timing --docurl=/hobbit/admin/notes.php?host=%s --rssversion=2.0 --eventignore=uptime,event,msgs,vmio,legato --includecolumns=graph --bb2-ignorecolumns=legato --rss" Thanks Francesco

2 1

[hobbit] oversized [ports] section && 'stopped reporting' -> feature request (bug ?)
by jjj863＠gmail.com 08 Aug '06

08 Aug '06

anyway the size limit can be applied invididually for each check, such that an oversized [ports] or any other section won't vitimize other 'good' sections and cause them dataless in the RRD? On 8/7/06, Jerry Yu <jjj863 at gmail.com> wrote: > > thanks, I doubled MAXMSG_CLIENT MAXMSG_STATUS as well as MAXMSG_DATA from > their default values. That seem to have eliminated the truncation line for > PORTS data and oversize status/stachg messages for Hobbitd. > after "/etc/init.d/hobbit stop" and 'kill -TERM' the remaining vmstat > processes, I had to 'ipcrm' one last shm segment. > > > On 8/6/06, Henrik Stoerner <henrik at hswn.dk> wrote: > > > > On Fri, Aug 04, 2006 at 09:54:04AM -0400, Jerry Yu wrote: > > > one of our servers have up to 6000 TIME_WAIT tcp connections from > > time to > > > time. This got truncated, of course. I want to see them all. any > > quick way > > > to change the upper limit w/o recompilation ? > > > > Set the MAXMSG_CLIENT setting in hobbitserver.cfg and restart Hobbit. > > The default is 512 (KB) for the maximum size of a client message. > > > > If you want them all to show up on the status display, you probably also > > > > have to increase the MAXMSG_STATUS setting. > > > > The hobbitserver.cfg man-page describes these. > > > > > > > Also, for the same server, from time to time, certain checks 'stopped > > > reporting' [ files & msgs, in particular ] for some extended period, > > > sometimes over 35m, while other checks kept going. I wonder if the > > message > > > truncation triggered by the over-sized [ports] section caused this > > loss. > > > > It could very well be due to this. The [files] and [msgs] sections of > > the client message appear after the network ports listing, so if the > > message was truncated these could be lost. > > > > > > Regards, > > Henrik > > > > > > To unsubscribe from the hobbit list, send an e-mail to > > hobbit-unsubscribe at hswn.dk > > > > > > >

2 1

Configuration Files (Feature Request / Question)
by rgordonjr＠gmail.com 08 Aug '06

08 Aug '06

Hello - It is my understanding that the configuration files located in $HOBBITROOT/etc are not overwritten during an upgrade. Where would I find the configuration files that would have been installed had this been a new installation? (A few of the admins are looking for them...) Any chance that the installer can be modified to save the default configuration files to $HOBBITROOT/etc/DIST (or some other directory) in the event of an upgrade installation? Thanks - -- --==[ Bob Gordon ]==--

3 2

MAX_DATA hard coded somewhere? <= was: oversized [ports] section
by jjj863＠gmail.com 08 Aug '06

08 Aug '06

I bumped up the MAXMSG_DATA and MAXMSG_STATUS again, to 768 from 512 (was 256 by default). restarted hobbit ok. the list of SHM via ipcs (appended below) shows the 768K segment is created. However, an hour later, I still ran into messages for hobbitd like this: Oversize data/client msg from 10.77.9.106 truncated (n=722041, limit 524288) This causes all sorts of problems: PROCS/MSGS/FILES got status CLEAR/Non-reporting or false alerts due to required processes are truncated from listings, plus rrddata not gathered for count of PROCS, etc. Questions 1) is MAX_DATA / MAX_STATUS hard-coded at 512K, somewhere? 2) any way to get around this ? The super-sized [ports] is here to stay for a few months at least. ---- "hobbitservers.cfg"---cut---- MAXMSG_CLIENT = 1024 MAXMSG_DATA = 768 MAXMSG_STATUS=768 ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x0101f2e0 2129920 hobbit 600 786432 2 0x0201f2e0 2162689 hobbit 600 786432 2 0x0301f2e0 2195458 hobbit 600 786432 2 0x0401f2e0 2228227 hobbit 600 262144 2 0x0501f2e0 2260996 hobbit 600 262144 1 0x0601f2e0 2293765 hobbit 600 32768 1 0x0701f2e0 2326534 hobbit 600 524288 2 0x0801f2e0 2359303 hobbit 600 524288 2 For regular user 'hobbit', ulimit don't have any limit set at 512K. [hobbit at saturn ~]$ ulimit -aH core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 16383 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [hobbit at saturn ~]$ ulimit -aS core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 16383 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

2 4

R: [hobbit] dialup directive not implemented?
by fduranti＠q8.it 08 Aug '06

08 Aug '06

Hi all, I'm also in need to a "iprange" test mostly for modem banks and vpn connected users... This kind of syntax will be much better then the old dialup style. If it will become a normal test with a normal output it could be nice to also have something like number of reachable/unreachable host in rrd format so that we can see how many users are connecting during the day... Another think interesting (don't know how many people will use it or need it) can be something like 0.0.0.0 vpnpool.foo.com # [!]iprange=172.16.1.1-172.16.1.100,[yellow number],[red number] So it can also be used to alert when for example you've only 5 connection available out of 100 or the reverse of this for example if of your 10 domain controller/webserver/dns server only 2 are up and running -----Messaggio originale----- Da: Henrik Stoerner [mailto:henrik at hswn.dk] Inviato: martedì 8 agosto 2006 17.35 A: hobbit at hswn.dk Oggetto: Re: [hobbit] dialup directive not implemented? On Tue, Aug 08, 2006 at 09:03:04AM -0500, Mike Serra wrote: > I have a simple question about the "dialup" directive in bb-hosts, the > one that is supposed to come immediately after a page or subpage > directive, and is used to ping a range of hosts, like a modem pool. > Our sysadmin tells me that he read (in a man page online?) that this > directive is not implemented. And it's acting like it isn't: we can't > get it to do anything, despite trying every possible syntax that could > make sense. But on the other hand people online talk about this as if > they're using it just fine. So -- is it implemented? We are using > hobbit version 4.2-beta-20060605. It was implemented some time ago, but I've had reports coming in over the past couple of months that it doesn't work in the 4.2 test releases that are out. I then asked if anyone was using it, because if not I'd prefer to just rip it out instead of trying to fix it - and so far noone has stepped forward to say they really need it. So ... do you need it ? If people want it, I'd really rather implement it quite differently than the old BB implementation - as a normal network test associated with a host, e.g. 0.0.0.0 vpnpool.foo.com # iprange=172.16.1.1-172.16.1.100 Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0