- Xymon - Xymon mailman web

[hobbit] minor client bug
by Larry.Barber＠usda.gov 16 Sep '05

16 Sep '05

It just happened again, the client data page had the full listing, the <defunct> tag had the ending ">" missing, but this may have been truncated due to line length. The cpu page didn't show any part of the <defunct> label and nothing of the top output after that label. Thanks, Larry Barber On Fri, 2005-09-16 at 16:22 -0500, Barber, Larry wrote: > If I recall correctly, the listing ended with "<defunct", with no > closing ">". It's gone by now and I didn't think to save it when I > looked at it. I may not be remembering correctly (it may have been > the > cpu page that had the "<defunct", not the client data page). If it > pops > up again I'll save a copy. FYI, I use Firefox for my browser. I don't > know if the same thing happens with IE or not. > > Thanks, > Larry Barber > > > On Fri, 2005-09-16 at 16:13 -0500, henrik at hswn.dk wrote: > > On Fri, Sep 16, 2005 at 04:55:33PM -0400, Larry.Barber at usda.gov > > wrote: > > > I've noticed that when the top listing includes a <defunct> > label, > > that > > > the top listing on the cpu page gets truncated at that point. > > Possibly > > > the ending '>' is getting interpreted as a the close of an html > tag? > > > > I think it's your browser that truncates the display at that point. > > If > > you click on the "Client data" link - does that include the full > > top/ps > > output ? It should, because that's sent with a content-type of > > "text/plain". > > > > > Would it be possible to filter those labels out? I suspect that > > same > > > thing happens with the ps output on the procs page, although I > > haven't > > > actually observed it. > > > > It should behave the same way, yes... It would make sense for > Hobbit > > to > > do some basic html-ification of the data before embedding it into > > the > > webpage. On the other hand, some of the status reports are > > pre-formatted > > as HTML, so those should be left alone. Hmm... > > > > > > Henrik > > > > > > To unsubscribe from the hobbit list, send an e-mail to > > hobbit-unsubscribe at hswn.dk > > > > > > > > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0

[hobbit] Very Weird ping issue
by Larry.Barber＠usda.gov 16 Sep '05

16 Sep '05

What happens if you put "testip" in your bb-hosts file? I suspect you might find that the names are being resolved incorrectly by DNS, try an nslookup from you BBNET machine, and see what you get. Thanks, Larry Barber On Fri, 2005-09-16 at 16:15 -0500, wes.neal at mci.com wrote: > I am having a problem with out of the 600 or so hosts I have right now > and > it is very odd. > > The four hosts in bb-hosts look like this: > > 166.47.52.23 MIREGA-XYP # > conn > 166.46.11.1 NRKANG-XYP # > conn > 166.42.132.19 ALMMGA-AI #conn > 166.39.161.143 ORLLFL-AI # conn > > The all 4 show up as red on the web page, but with not those IP > addresses. > As a matter of fact the IPs they show as aren't anywhere in my > bb-hosts > file. > The emails that are generated even have the wrong IPs as well, they > look > like this: > > red Fri Sep 16 10:09:39 2005 conn NOT ok > Service conn on ALMMGA-AI is not OK : Host does not respond to ping > System unreachable for 9552 poll periods (3195617 seconds) > &red 10.8.2.126 is unreachable > > red Fri Sep 16 10:09:39 2005 conn NOT ok > Service conn on MIREGA-XYP is not OK : Host does not respond to ping > System unreachable for 9552 poll periods (3195617 seconds) > &red 166.47.118.231 is unreachable > > As you can see those aren't the IPs in the bb-hosts file. I have > commented > out the lines in the bb-hosts file and done a: > > bb 127.0.0.1 "drop MIREGA-XYP" for all of the hosts. This got rid of > them, > but when I put them back in, they came right back red with the same > bad IPs. > > What could possibly be causing this? > > Thanks > Wes > > > > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0

[hobbit] Monitoring processes in a Service Guard environment
by tbarnes1＠hfhs.org 16 Sep '05

16 Sep '05

Ok - thanks Henrik. That second option on your, I am sure very long, to-do list would be great. I have an acceptable solution for now, not great - but acceptable. Terry Barnes Siemens Com @ HFHS 248-853-4968 (Office) 586-489-4513 (Cellular) 248-844-3030 (Fax) tbarnes1 at hfhs.org >>> henrik at hswn.dk 9/16/05 5:05:27 PM >>> On Fri, Sep 16, 2005 at 12:17:17PM -0400, Terry Barnes wrote: > We recently changed several of our systems that are managed by Service Guard to automatic failover. They were previously a manual failover only. Now - it is impossible to predict which system in the cluster will have the critical processes active. The Service Guard managed pseudo hostname and IP address, as well as disk, processes, etc. may be on any system in the cluster at any time. I run a client on each system in the cluster, but cannot monitor the processes effectively. > > 1. Is there a way to run a client against the Service Guard owned hostname and IP address? > 2. How well would adding the client to the cluster work? Inother words, if the package switches to another host system in the cluster, so would the client. The actual hostname of the new system would be different and I am guessing this would cause problems. I think 2) answers your 1). Let the client migrate along with the other critical processes, and it shouldn't be a problem to check if those processes are running. The Hobbit client picks up the hostname from the "uname -n" command command, but you can start it with a "--hostname=MY.PSEUDO.HOSTNAME" (at least in the current snapshot) and it will use that instead. Another solution that I am looking at - it was suggested some time ago here on the list - is to have a process check that isn't related to any one host, but rather goes like "process foo must run on N of the nodes X, Y and Z". (E.g. "httpd" must be running on at least 5 out of our 10 web servers). That is on the to-do list. Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk ============================================================================== Go to http://henryford.com We're Henry Ford. We Can. HFHS CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by replying in an email to the sender, delete the email from your computer system and shred any paper copies of the email you printed. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. These risks are described in our Privacy Policy at http://henryford.com. Review that policy carefully before continuing to communicate with us by e-mail. For greater Internet security, our policy describes the Henry Ford MyHealth electronic communication process - you may register at http://henryford.com. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. ==============================================================================

1 0

[hobbit] minor client bug
by Larry.Barber＠usda.gov 16 Sep '05

16 Sep '05

If I recall correctly, the listing ended with "<defunct", with no closing ">". It's gone by now and I didn't think to save it when I looked at it. I may not be remembering correctly (it may have been the cpu page that had the "<defunct", not the client data page). If it pops up again I'll save a copy. FYI, I use Firefox for my browser. I don't know if the same thing happens with IE or not. Thanks, Larry Barber On Fri, 2005-09-16 at 16:13 -0500, henrik at hswn.dk wrote: > On Fri, Sep 16, 2005 at 04:55:33PM -0400, Larry.Barber at usda.gov > wrote: > > I've noticed that when the top listing includes a <defunct> label, > that > > the top listing on the cpu page gets truncated at that point. > Possibly > > the ending '>' is getting interpreted as a the close of an html tag? > > I think it's your browser that truncates the display at that point. > If > you click on the "Client data" link - does that include the full > top/ps > output ? It should, because that's sent with a content-type of > "text/plain". > > > Would it be possible to filter those labels out? I suspect that > same > > thing happens with the ps output on the procs page, although I > haven't > > actually observed it. > > It should behave the same way, yes... It would make sense for Hobbit > to > do some basic html-ification of the data before embedding it into > the > webpage. On the other hand, some of the status reports are > pre-formatted > as HTML, so those should be left alone. Hmm... > > > Henrik > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0

[hobbit] minor client bug
by henrik＠hswn.dk 16 Sep '05

16 Sep '05

On Fri, Sep 16, 2005 at 04:55:33PM -0400, Larry.Barber at usda.gov wrote: > I've noticed that when the top listing includes a <defunct> label, that > the top listing on the cpu page gets truncated at that point. Possibly > the ending '>' is getting interpreted as a the close of an html tag? I think it's your browser that truncates the display at that point. If you click on the "Client data" link - does that include the full top/ps output ? It should, because that's sent with a content-type of "text/plain". > Would it be possible to filter those labels out? I suspect that same > thing happens with the ps output on the procs page, although I haven't > actually observed it. It should behave the same way, yes... It would make sense for Hobbit to do some basic html-ification of the data before embedding it into the webpage. On the other hand, some of the status reports are pre-formatted as HTML, so those should be left alone. Hmm... Henrik

1 0

Monitoring processes in a Service Guard environment
by tbarnes1＠hfhs.org 16 Sep '05

16 Sep '05

We recently changed several of our systems that are managed by Service Guard to automatic failover. They were previously a manual failover only. Now - it is impossible to predict which system in the cluster will have the critical processes active. The Service Guard managed pseudo hostname and IP address, as well as disk, processes, etc. may be on any system in the cluster at any time. I run a client on each system in the cluster, but cannot monitor the processes effectively. 1. Is there a way to run a client against the Service Guard owned hostname and IP address? 2. How well would adding the client to the cluster work? Inother words, if the package switches to another host system in the cluster, so would the client. The actual hostname of the new system would be different and I am guessing this would cause problems. 3. Any other ideas how to effectively monitor Service Guard controlled processes? Thanks! Terry Barnes Siemens Com @ HFHS 248-853-4968 (Office) 586-489-4513 (Cellular) 248-844-3030 (Fax) tbarnes1 at hfhs.org ============================================================================== Go to http://henryford.com We're Henry Ford. We Can. HFHS CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by replying in an email to the sender, delete the email from your computer system and shred any paper copies of the email you printed. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. These risks are described in our Privacy Policy at http://henryford.com. Review that policy carefully before continuing to communicate with us by e-mail. For greater Internet security, our policy describes the Henry Ford MyHealth electronic communication process - you may register at http://henryford.com. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us. ==============================================================================

3 2

Fatal signal caught!
by bigdan＠gmail.com 16 Sep '05

16 Sep '05

Hello all, Looks like I found the favorite crash in hobbit. I am running 4.1.1 and just "upgraded" from bb. I followed the bb->hobbit instructions to the t and everything appears to be working except for this test ( and the tests associated with it ). I tried commenting out everything but one line in my bb-hosts, but it just seems like if I have more than one test it croaks with a seg fault. Here: Environment BBLOCATION='' Environment CONNTEST='TRUE' Environment IPTEST_2_CLEAR_ON_FAILED_CONN='TRUE' Service list dump ./bbcmd bbtest-net --debug --ping --checkresponse (skip few dozen lines) 2005-09-16 11:11:20 Got DNS result for host server : <ip> 2005-09-16 11:11:20 Adding tcp test IP=<ip>, port=143, service=imap, silent=0 Aborted (core dumped) (gdb) file bbtest-net Reading symbols from bbtest-net...done. unknown option `--debug' (gdb) run Starting program: /home/monitor/server/bin/bbtest-net Program received signal SIGSEGV, Segmentation fault. 0x08050571 in add_tcp_test (ip=0x809806c "24.220.8.53", port=143, service=0xbffff9fc "imap", sslopt=0x0, silent=0, reqmsg=0x0, priv=0x0, datacallback=0, finalcallback=0) at contest.c:182 182 newtest->sendtxt = (reqmsg ? reqmsg : newtest->svcinfo->sendtxt); It dies on the first host it loads the tests for. Here is my first host: page mail Mail servers group-compress <ip> mailserver # smtp pop3 imap ssh !dns !ftp Anyone have any hints on what to do? What happens on this line: newtest->sendtxt = (reqmsg ? reqmsg : newtest->svcinfo->sendtxt); ? If I knew C, I'd contribute:) Thanks Dan

2 3

minor client bug
by Larry.Barber＠usda.gov 16 Sep '05

16 Sep '05

I've noticed that when the top listing includes a <defunct> label, that the top listing on the cpu page gets truncated at that point. Possibly the ending '>' is getting interpreted as a the close of an html tag? Would it be possible to filter those labels out? I suspect that same thing happens with the ps output on the procs page, although I haven't actually observed it. Thanks, Larry Barber

1 0

[hobbit] how create a new link without a service !?
by waldirio.spassu＠petrobras.com.br 16 Sep '05

16 Sep '05

Hi Henrik My real necessity is create one new link "not change or create description", but one new link where I dont need make any test. For example, create a new collum called new_service and in this collum, I made one link for other page (dont create by hobbit, but for my ;D). Best Regards Waldirio Manhães Pinheiro |---------+-------------------------------> | | henrik at hswn.dk | | | (Henrik Stoerner) | | | | | | 16/09/2005 11:50 | | | Responder a hobbit | | | | |---------+-------------------------------> >----------------------------------------------------------------------------------------------------------------------------| | | | Para: hobbit at hswn.dk | | cc: (cco: Waldirio Manhaes Pinheiro - SPASSU/BC/Petrobras) | | Assunto: Re: [hobbit] how create a new link without a service !? | >----------------------------------------------------------------------------------------------------------------------------| On Fri, Sep 16, 2005 at 07:31:51AM -0300, waldirio.spassu at petrobras.com.br wrote: > > How can I create a new link, without the same exists as a service?! I need > to add a link for one it makes up that already contains a consultation > (PHP+MySQL). You mean a description of what the column is for ? It's in the ~hobbit/server/etc/columndoc.csv file - just add a line with the name of the column and the (HTML) description, separated by a semi-colon. Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk "O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe ao destinatário cuidar quanto ao tratamento adequado. Sem a devida autorização, a divulgação, a reprodução, a distribuição ou qualquer outra ação em desconformidade com as normas internas do Sistema Petrobras são proibidas e passíveis de sanção disciplinar, cível e criminal." "The sender of this message is responsible for its content and addressing. The receiver shall take proper care of it. Without due authorization, the publication, reproduction, distribution or the performance of any other action not conforming to Petrobras System internal policies and procedures is forbidden and liable to disciplinary, civil or criminal sanctions." " El emisor de este mensaje es responsable por su contenido y direccionamiento. Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorización, su divulgación, reproducción, distribución o cualquier otra acción no conforme a las normas internas del Sistema Petrobras están prohibidas y serán pasibles de sanción disciplinaria, civil y penal."

1 0

Repeat paging without REPEAT
by hobbit＠pvaughan.us 16 Sep '05

16 Sep '05

I have some hosts that were set to repeatedly page every 20 minutes for 2 hours. Of course, when an entire team got into a meeting and they all got the same page every 20 minutes for an hour, I was told to turn that "feature" off. But, after removing the REPEAT keyword in the hobbit-alerts.cfg file I got the pages this morning at 8:00 AM and 8:30 AM. The time restriction keywords worked perfectly, but I don't see where I'm getting the repeats from. I also stopped and restarted hobbitd after editing the file. Here are the relevant lines from my hobbit-alerts.cfg: HOST=%(cnpe|cnpf|cnpg|cnph).pri.xxx.net|hnae.ro.xxx.net SCRIPT /usr/local/bin/scripts/hobbit-mailpage $UNIX_PAGERMAIL SERVICE=%(cpu|disk|errpt|msgs|procs|ssh|telnet|vmio) COLOR=red TIME=12345:0800:1700 SCRIPT /usr/local/bin/scripts/hobbit-mailpage $MIDDLEWARE_PAGERMAIL SERVICE=%(cpu|disk|errpt|msgs|procs|ssh|telnet|vmio) COLOR=red TIME=12345:0800:1700

2 1