Current snapshot compilation problem
list Alexandre Levin
Hi, I've got a compilation problem with current snapshot: ... hobbit_snmpcollect.c:1068: error: 'PATH_MAX' undeclared (first use in this function) ... Adding: #include <limits.h> To the hobbit_snmpcollect.c solved it OS - FreeBSD 7.0 Alexandre Levin
list Henrik Størner
Thanks Alexandre, done that on my sourcefile. Regards, Henrik
▸
On Mon, Jan 14, 2008 at 01:16:09PM -0800, Levin, Alexandre wrote:... hobbit_snmpcollect.c:1068: error: 'PATH_MAX' undeclared (first use in this function) ... Adding: #include <limits.h> To the hobbit_snmpcollect.c solved it
list Vernon Everett
Hi all Has anybody done anything regarding monitoring acsls software and/or associated tape drives/arrays? For those wondering, I am refering to this product. http://www.sun.com/storagetek/tape_storage/tape_software/acsls/index.xml Regards Vernon NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.
list Vernon Everett
Hi everybody Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause. Is there a common script that updates these 4 rrd graphs? Or something else common to these four graphs only? All my other graphs disk, cpu, memory, the lot, are all working fine. These are a mixture of Solaris and Linux clients, so I suspect it's not a client-side issue. I thought it may have been corruption of the files, but it seems unlikely to happen for only those 4 rrd files for all 300-odd servers. All four stopped updating at exactly the same time. Naturally, the graphs are blank too. Has anybody seen anything like this? Any help appreciated.
▸
Regards
Vernon
NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.
list Charles Goyard
▸
Everett, Vernon wrote :
Hi everybody Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause.
Hey, I had the exact same problem on SCO servers a few weeks ago (24th of december, around 6am). So far I found no solution and no useful log message. -- Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie
list H. Klomp
Have You checked the permissions of the rrd files and directories ? Regards, H. Klomp National Aerospace Laboratory NLR Computer Infrastructure Development Dedicated to innovation in aerospace
▸
-----Original Message-----
From: Charles Goyard [mailto:user-a6cdca7046e2@xymon.invalid]
Sent: dinsdag 15 januari 2008 11:34
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Rrd not updating
Everett, Vernon wrote :Hi everybody Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause.
Hey, I had the exact same problem on SCO servers a few weeks ago (24th of december, around 6am). So far I found no solution and no useful log message. -- Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie
list Charles Goyard
Yes, I even removed all the rrds, and disk were rebuilt while la, procs and users were not.
▸
Klomp, H. wrote :Have You checked the permissions of the rrd files and directories ? Everett, Vernon wrote :Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause.
-- Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie
list Henrik Størner
▸
On Tue, Jan 15, 2008 at 04:33:25PM +0900, Everett, Vernon wrote:
Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause. Is there a common script that updates these 4 rrd graphs? Or something else common to these four graphs only?
All of these graphs are fed by data in the "cpu" status. Have you changed your TEST2RRD setting ? It should have a "cpu=la" in there. Henrik
list Vernon Everett
Fantastic! Henrik, you did it again. Somehow, the entry was changed to "cpu,la", which obviously wouldn't work. I'll chalk that up as yet another beer I owe you when you visit Perth. :-) Thanks Vernon
▸
-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Wednesday, 16 January 2008 6:43 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Rrd not updating
On Tue, Jan 15, 2008 at 04:33:25PM +0900, Everett, Vernon wrote:Here's a peculiar problem. All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause. Is there a common script that updates these 4 rrd graphs? Or something else common to these four graphs only?
All of these graphs are fed by data in the "cpu" status. Have you changed your TEST2RRD setting ? It should have a "cpu=la" in there. Henrik NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.
list Charles Goyard
Hi, this is a follow-up to a old question, but we found a solution today :)
▸
Charles Goyard wrote :Everett, Vernon wrote :All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause.I had the exact same problem on SCO servers a few weeks ago (24th of december, around 6am).
On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:"). Reboot of the system solves the problem :). Regards,
▸
--
Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31
Orange Business Services - online multimedia // ingénierie
list S Aiello
▸
On Tuesday 25 March 2008, Charles Goyard wrote:
Hi, this is a follow-up to a old question, but we found a solution today :) Charles Goyard wrote :Everett, Vernon wrote :All of a sudden, users.rrd, procs.rrd, la.rrd and clock.rrd have stopped updating. Actually, it happened on Friday, but I still haven't found the cause.I had the exact same problem on SCO servers a few weeks ago (24th of december, around 6am).On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:"). Reboot of the system solves the problem :).
I don't have the luxury of rebooting, so I threw a quick pipe to awk that checks for the number of uptime fields... and adds the 999 for the 'days up' field, if that field is missing. I can paste the exact awk command if desired. ~Steve
list Henrik Størner
▸
On Tue, Mar 25, 2008 at 02:12:42PM +0100, Charles Goyard wrote:
On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:").
Ahh - the old 31-bit timer tick issue. Linux has the same problem because a timer ticks at 100 Hz using a signed 32-bit integer; so 2^31 / (24*60*60*100) = 248 days and a bit.
Reboot of the system solves the problem :).
Add UP 1h 240d to hobbit-clients.cfg to get a reminder 8 days before it happens. Regards, Henrik
▸
Regards, -- Charles Goyard - user-a6cdca7046e2@xymon.invalid - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie
--
Henrik Storner
list Joe Sloan
▸
Henrik Stoerner wrote:
On Tue, Mar 25, 2008 at 02:12:42PM +0100, Charles Goyard wrote:On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:").Ahh - the old 31-bit timer tick issue. Linux has the same problem because a timer ticks at 100 Hz using a signed 32-bit integer; so 2^31 / (24*60*60*100) = 248 days and a bit.
That's news to me - root at ashpool:~> uptime 8:39am up 1075 days 20:10, 1 user, load average: 3.11, 3.13, 3.07 root at ashpool:~> uname -a Linux ashpool 2.6.5-7.151-smp #1 SMP Fri Mar 18 11:31:21 UTC 2005 i686 i686 i386 GNU/Linux Joe
list Henrik Størner
▸
On Tue, Mar 25, 2008 at 09:40:12AM -0700, Sloan wrote:
Henrik Stoerner wrote:On Tue, Mar 25, 2008 at 02:12:42PM +0100, Charles Goyard wrote:On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:").Ahh - the old 31-bit timer tick issue. Linux has the same problem because a timer ticks at 100 Hz using a signed 32-bit integer; so 2^31 / (24*60*60*100) = 248 days and a bit.That's news to me -
Sorry, I should have written "Linux HAD the same problem" (past tense). This was fixed somewhere in the early 2.4.x kernels. That's why I wrote it was the "old" problem. Henrik
list Joe Sloan
▸
Henrik Stoerner wrote:
On Tue, Mar 25, 2008 at 09:40:12AM -0700, Sloan wrote:Henrik Stoerner wrote:On Tue, Mar 25, 2008 at 02:12:42PM +0100, Charles Goyard wrote:On our setup, the problem comes from a counter overflow in uptime handling on some SCO : after 248 days of uptime, the uptime is reported negative, and the rrd handler misses the expression (no "up:").Ahh - the old 31-bit timer tick issue. Linux has the same problem because a timer ticks at 100 Hz using a signed 32-bit integer; so 2^31 / (24*60*60*100) = 248 days and a bit.That's news to me -Sorry, I should have written "Linux HAD the same problem" (past tense). This was fixed somewhere in the early 2.4.x kernels. That's why I wrote it was the "old" problem.
Yes, linux used to wrap around at 497 days uptime, so it must have been unsigned int. Joe