atom feed10 messages in net.sourceforge.lists.nagios-usersRe: [Nagios-users] Nagios retention p...
FromSent OnAttachments
Mark...@teliasonera.comNov 7, 2008 1:49 am 
Andreas EricssonNov 7, 2008 6:07 am 
Mark...@teliasonera.comNov 7, 2008 6:52 am 
Mark...@teliasonera.comNov 14, 2008 4:50 am 
Andreas EricssonNov 14, 2008 5:11 am 
Novak, MarkNov 14, 2008 8:40 am 
Marc PowellNov 14, 2008 9:16 am 
Fernando RochaNov 14, 2008 9:46 am 
Mark...@teliasonera.comNov 19, 2008 4:38 am 
Andreas EricssonNov 20, 2008 1:28 am 
Subject:Re: [Nagios-users] Nagios retention problem.
From:Mark...@teliasonera.com (Mark@teliasonera.com)
Date:Nov 19, 2008 4:38:55 am
List:net.sourceforge.lists.nagios-users

I move this thred to 'dev' instead. It seems to fit better there.

Problem solved.

Nagios does'nt check the return value from the fclose() call when closing the tempfile used to write retention.dat. Before I upgraded to Nagios 3 I hade severe performance problems, so I moved all temp-files to ramdisks for higher performance which worked well. But when the number of services increased after upgrading the ramdisk was'nt big enough.

Since there were no log entry, and the ramdisks were only about 40-50% full, I did'nt think this was the problem - after all the ramdisk were only 100% full between the closing of the tempfile until Nagios changed the name of the tempfile to "retention.dat".

Anyway. I've rewritten the code a little so that Nagios checks the fclose() return value, and if there is a problem a log entry is written. Also Nagios does not change the name of the tempfile, so the old retention data is saved instead of the new corropt data.

Are you people interested in the patch?

Best Regards /Markus almroth

-----Original Message----- From: Andreas Ericsson [mailto:ae@op5.se] Sent: den 14 november 2008 14:12 To: Almroth, Markus M. Cc: nagi@lists.sourceforge.net Subject: Re: [Nagios-users] Nagios retention problem.

Mark@teliasonera.com wrote:

Does anybody know if Nagios _always_ write the retention file when reloading/restarting?

It writes the retention file with rather frequent intervals, such as when it has done "enough" checks (where "enough" is determined sort of intelligently on a per-installation basis).

Didn't the command-file trick work for you?