Nagios DST bug and upcoming DST-time switch in Europe

[Frost, Mark {PBC}]

>-----Original Message-----
>From: Ton Voon [mailto:ton.voon at opsera.com] 
>Sent: Tuesday, March 09, 2010 3:33 AM
>To: Nagios Users Mailinglist
>Subject: Re: [Nagios-users] Nagios DST bug and upcoming DST-time switch in Europe
>
>
>On 9 Mar 2010, at 08:19, Mark Elsen wrote:
>
>> Nagios 3.2.0
>> --------------------
>>
>> - By the end of the month, Europe will switch to DST.
>>   Will I be affected by the Nagios DST-BUG which , which results in
>> NAGIOS becoming
>>   dis-functional ?
>>
>> Which countermeasures can I take to prevent being struck by this  
>> problem ?
>>
>
>The bug, which stops all Nagios monitoring for 24 hours, occurs when  
>"time moves backwards". This does not happen when "time moves  
>forward". However, any other timeperiods (such as 09:00-17:00) maybe  
>incorrect by an hour, which is obviously not as serious. This is true  
>for Nagios 3.2.0.
>
>Ton

Unless I'm mistaken, we had this timeperiod problem occur here.  Some
alerts were sent during a timeperiod for which notifications
are not enabled.  I did restart Nagios after DST went into affect
just for fun, but that was before these alerts went out.

I know that the fix for this when this bug was evidenced last fall
was to run a script against one of the .dat files (retention.dat?).
However, that was for the monitoring problem.  Is there something
similar that we need to do to correct timeperiods?

Thanks

Mark

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null