On 26 Oct 2009, at 12:53, Matthias Flacke wrote:
this change is causing the wrong reschedule:
http://nagios.cvs.sourceforge.net/viewvc/nagios/nagios/base/utils.c?r1=1.236&r2=1.237&view=patch
It has been applied on 15th of January 2009 and introduced some
statements
t->tm_isdst=-1;
into base/utils.c.
Affected are all Nagios versions >= 3.1.0.
I could reproduce it here: if the patch above is backed out, the
scheduling behaves correctly.
I've managed to get a libtap test case with the failure now. As you
correctly say, removing the t->tm_isdst=-1 in utils.c fixes it.
However, the fact it works is lucky.
The check is that the scheduled time is between a date_range_start and
a date_range_end. This date_range_end is based on the timeperiod
definitions. However, an end point of 00:00 is calculated as 24*60*60.
Obviously, this is wrong on the day that the clocks go back as there
are 25 hours in that day.
So removing tm_isdst gets the calculation for the epoch time wrong,
but that luckily works because the time falls within the 24 hour period.
I've applied the patch to remove that single tm_isdst.
Tests are also added now, for this specific issue.
Long term, I think it is correct that the isdst flag be set, but there
are other problems that are lurking in the code, such as the
calculation for the next appropriate time.
Any comments?
Ton
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Nagios-users mailing list
Nagios-users@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
