[RFC] - strange issue on notification filter aka time is not like time?

[Andreas Ericsson]

Hendrik Baecker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Hi list,
> 
> I've just ran into a interesting problem with my nagios 3.1.0 code.
> 
> Intro:
> Take a host with two differenct contactgroups assigned.
> One of those cg should notify during daylight (tp-definition:
> 0800-1700 for example)
> and the other contactgroup with one contact member for only non
> daylight notifications (tp: 1700-2400,0000-0800).
> 
> Nagios is sending out a notification to all possible contacts,
> ignoring the notification_period of the contact.
> 
> I've already double checked the configs (regarding objects.cache as a
> result of all possible template resolutions).
> Possible needed config snipplet at the bottom of this message.
> 
> Enabled debugging:
> # nagios.debug - debug level '-1', debug verobosity '2':
> [1242118526.292017] [001.0] [pid=1052] notify_contact_of_host()
> [1242118526.292025] [032.2] [pid=1052] ** Attempting to notifying
> contact 'bereitschaftshandy1'...
> [1242118526.292034] [001.0] [pid=1052]
> check_contact_host_notification_viability()
> [1242118526.292043] [032.2] [pid=1052] ** Checking host notification
> viability for contact 'bereitschaftshandy1'...
> [1242118526.292052] [001.0] [pid=1052] check_time_against_period()
> [1242118526.292108] [032.2] [pid=1052] ** Host notification viability
> for contact 'bereitschaftshandy1' PASSED.
> [1242118526.292118] [032.2] [pid=1052] ** Notifying contact
> 'bereitschaftshandy1'
> 
> So the contact host notification filter ends up in PASSED state. (Btw.
> Same behavior on service checks)
> 
> And now it's getting funny.
> 
> In base/notifications.c beginning at line 1414 (latest cvs code) we found:
> - -------------------------------
> if(check_time_against_period(time(NULL),cntct->service_notification_period_ptr)==ERROR){
> ...
> ...
> - -------------------------------
> 
> time(NULL) should and possibly will return seconds since epoch, so far
> so good.
> 
> But if I change the check_time_against_period() call to this:
> 
> - -------------------------------
> time_t current_time;
> time(&current_time);
> if(check_time_against_period(current_time,cntct->host_notification_period_ptr)==ERROR){
> ...
> ...
> - -------------------------------
> 
> The notification periods works as expected and my
> 'bereitschaftshandy1' contact won't get a daylight notification.
> 
> Can someone please tell me, that it shouldn't matter what I've changed?
> 


The change shouldn't matter in the slightest, unless your compiler is doing
something strange and optimizes the call to time() away when it really
shouldn't. It could though, if the stack is clobbered somehow. Enabling
-Wmissing-prototypes and see if that triggers anything in the functions
in question should give you a clue in that case.

Can you run this small piece of code and let me know what you get?

#include <stdio.h>
#include <time.h>
int main(void)
{
	time_t now, ret;
	ret = time(NULL);
	printf("ret: %lu\n", ret);
	ret = time(&now);
	printf("ret: %lu\n", ret);
	printf("time(NULL): %lu\n", time(NULL));
	printf("time(&now): %lu\n", time(&now));

	return 0;
}

Here, I get
ret: 1242137092
ret: 1242137092
time(NULL): 1242137092
time(&now): 1242137092

right now, which is the expected behaviour. If either of your figures
don't match up (barring 1sec difference in case your clock ticks, ofc),
something is wrong in your library.

Also, it might be worth trying to recompile Nagios with -O1 instead of
-O2 and re-run the notification debugging. That will turn off sibling
call optimization and should make gcc take slightly better care of the
stack.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com