[hobbit] RHEL5 and status-board not available bug?
----- Original Message ----- From: "Buchan Milne" <bgmilne at staff.telkomsa.net>
News about my problem. Moved to RHEL5.3 32bit with PAE kernel, with the same architecture, data on NFS, bonding and veritas cluster like before. The problem is dissappear.
So, I repeat, just on 64bit RHEL => 5.0 seems appear the bug.
So, you need to check your storage system.
Well, like I told, the problem persist also on local disk with 64bit.
My workstation is running RHEL 5.2 on a Sun Ultra 40, and Hobbit ...cut... and I've never seen this.
5.2 on sun, the kernel is different of amd/intel Which version of kernel are you using?
In the production environment, my hobbit on RHEL5 x86_64 is only doing polling/testing/proxying (the display is on a RHEL4 i386).
hum...maybe problem related to bbgen? Mine was a bbdisplay and bbnet on the same server.
-- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com
On Monday 16 February 2009 17:15:34 Flyzone Micky wrote:
----- Original Message ----- From: "Buchan Milne" <bgmilne at staff.telkomsa.net>
News about my problem. Moved to RHEL5.3 32bit with PAE kernel, with the same architecture, data on NFS, bonding and veritas cluster like before. The problem is dissappear.
So, I repeat, just on 64bit RHEL => 5.0 seems appear the bug.
So, you need to check your storage system.
Well, like I told, the problem persist also on local disk with 64bit.
My workstation is running RHEL 5.2 on a Sun Ultra 40, and Hobbit
...cut...
and I've never seen this.
5.2 on sun, the kernel is different of amd/intel Which version of kernel are you using?
No, Intel/AMD makes no difference, x86_64 (EM64T for Intel, amd64 for AMD) vs i386 does, but:
Linux seaknight.telkomsa.net 2.6.18-92.1.10.el5xen #1 SMP Wed Jul 23 04:11:52 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
cat /proc/cpuinfo
processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2210 stepping : 2 cpu MHz : 1800.000 cache size : 1024 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 4501.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc
processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2210 stepping : 2 cpu MHz : 1800.000 cache size : 1024 KB physical id : 1 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 4501.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc
processor : 2 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2210 stepping : 2 cpu MHz : 1800.000 cache size : 1024 KB physical id : 2 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 4501.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc
processor : 3 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2210 stepping : 2 cpu MHz : 1800.000 cache size : 1024 KB physical id : 3 siblings : 1 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 4501.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc
In the production environment, my hobbit on RHEL5 x86_64 is only doing polling/testing/proxying (the display is on a RHEL4 i386).
hum...maybe problem related to bbgen?
Not bbgen itself, as you said you get "Status not available", which is not a static html page from bbgen, but usually from bb-hostsvc.sh (calling hobbitsvc.cgi).
You may first want to deteremine whether the cgi is timing out speaking to hobbitd, or if there is some other problem.
Mine was a bbdisplay and bbnet on the same server.
Yes, in my production environment, problems with hobbitd on the RHEL5 x86_64 box would not result in any noticeable problems, but again, my workstation doesn't exhibit this problem (and I usually have about 10 tabs open on different hobbit pages, including static and cgi ones, looking at my workstation's hobbit install).
Regards, Buchan
I looked through the archives but couldn't find an answer here - basically with HPUX v3 I get a permanent red flag:
/dev/deviceFileSystem (100% used) has reached the PANIC level (95%)
From the start: Filesystem 1024-blocks Used Available Capacity Mounted on DevFS 0 0 0 100% /dev/deviceFileSystem
How do I ignore JUST that filesytem?
B
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you.
I put:
DISK "/dev/deviceFileSytem" IGNORE
In my hobbit-client.cfg for my rx6600 machines running HPUX 11v3 and that works fine. It is not an HPUX 11v3 thing, it is specific to the hardware. My rx7640 running HPUX 11v3, but does not need the entry because this hardware platform does not need this file system for its devices.
.....BruceDisclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc.
-----Original Message----- From: Brian O'Mahony [mailto:brian.omahony at curamsoftware.com] Sent: Monday, February 16, 2009 10:35 AM To: hobbit at hswn.dk Subject: [hobbit] HPUX v11.31 - disk status red
I looked through the archives but couldn't find an answer here - basically with HPUX v3 I get a permanent red flag:
/dev/deviceFileSystem (100% used) has reached the PANIC level (95%)
From the start: Filesystem 1024-blocks Used Available Capacity Mounted on DevFS 0 0 0 100% /dev/deviceFileSystem
How do I ignore JUST that filesytem?
B
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Mon, Feb 16, 2009 at 03:15:34PM +0000, Flyzone Micky wrote:
----- Original Message ----- From: "Buchan Milne" <bgmilne at staff.telkomsa.net>
News about my problem. Moved to RHEL5.3 32bit with PAE kernel, with the same architecture, data on NFS, bonding and veritas cluster like before. The problem is dissappear.
So, I repeat, just on 64bit RHEL => 5.0 seems appear the bug.
Without any more data to go on, I cannot see that there is an indication of this being a Xymon bug.
I'll consider it a bug in the RHEL x86-64 kernel until there is data to prove me wrong.
Henrik
participants (5)
-
bewhite＠fellowes.com
-
bgmilne＠staff.telkomsa.net
-
brian.omahony＠curamsoftware.com
-
flyzone＠technologist.com
-
henrik＠hswn.dk