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.

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 - charles.goyard at orange-ftgroup.com - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie

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 - charles.goyard at orange-ftgroup.com - (+33) 1 45 38 01 31 Orange Business Services - online multimedia // ingénierie

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

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

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

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:henrik at hswn.dk] Sent: Wednesday, 16 January 2008 6:43 AM To: hobbit at hswn.dk 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

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

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.