<div>Hi,</div> <div>Have not seen anything on this in a bit, is there patch available for this (Version 3.1.2)? I would hate to hit this again next year :)</div> <div>Take it Easy</div> <div>Eric </div> <div class="gmail_quote">On Tue, Nov 3, 2009 at 8:09 AM, Ton Voon <<a href="mailto:ton.voon@opsera.com">ton.voon@opsera.com</a>> wrote: <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi Albrecht, On 3 Dec 2008, at 20:01, Albrecht Dreß wrote: > Am 01.12.08 21:59 schrieb(en) Albrecht Dreß: >> I have a self-compiled nagios 3.0.5 running on a 64-bit Xeon box >> with Ubuntu 8.04 LTS. Everything went perfectly (including >> notifications) until I upgraded from 3.0.1 (iirc) to 3.0.5 during a >> bigger service downtime (inter alia shifting the box into an other >> network etc). > > After adding tons of debug messages, I was finally able to track > down the problem. The problem is that I added a german holiday in > the form > > october 3 00:00-00:00 > > In function (all inbase/utils.c) check_time_against_period(), the > start time was calculated by calculate_time_from_day_of_month() as > 1222988400 (Fri Oct 3 01:00:00 2008), but the end time as > 1222984800 (Fri Oct 3 00:00:00 2008), which is /before/ the start, > and therefore the time span was expanded to a whole year, i.e. the > end now was Oct 3, 2009... > > Looking deeper into function calculate_time_from_day_of_month(), > this is apparently caused by a wrong usage of the call to mktime(), > as the field tm_isdst is /not/ initialised properly. The observed 1 > hour offset seems to come from an earlier call to this function > which returned an active dst flag. > > According to the IEEE Std 1003.1 [1], the field tm_isdst /is/ used > in the time conversion, and should be set to -1 if the dst status is > unknown (you may want to write a small test app, setting this flag > to -1, 0 or 1 to observe the effect). As mktime() is used > frequently in the code without properly initialising this field, > this seems to be a systematic bug which can trigger interesting > effects in nagios. > > Any opinions? As you are probably aware, this change has caused the DST bug that has affected a lot of users of Nagios 3.2.0. I have only reverted one instance of the tm_isdst field, which was specifically causing the rescheduling problem. There is a testcase in HEAD ( download from <a href="http://nagios.sourceforge.net/download/cvs/nagios-HEAD.tar.gz" target="_blank">http://nagios.sourceforge.net/download/cvs/nagios-HEAD.tar.gz</a> && ./configure --enable-libtap && make all && make test) which tests the DST bug (see t-tap/check_timeperiods.c). However, I think some of the other isdst settings maybe causing other bugs, though I'm not sure. It would be helpful if you could add some test for the problem you have fixed, to prove that the functionality you expect continues to work. I'd be happy to apply to CVS if you have an updated check_timeperiods.c file. 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! <a href="http://p.sf.net/sfu/devconference" target="_blank">http://p.sf.net/sfu/devconference</a> _______________________________________________ Nagios-users mailing list <a href="mailto:Nagios-users@lists.sourceforge.net">Nagios-users@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/nagios-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-users</a> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null </blockquote></div>