according to manual:
first_notification_delay: This directive is used to define the number of
"time units" to wait before sending out the first problem notification wh=
en
this host enters a non-UP state. Unless you've changed the interval_lengt=
h
directive from the default value of 60, this number will mean minutes. If
you set this value to 0, Nagios will start sending out notifications
immediately.=20
However, it may send notification earlier, because time is counted starti=
ng
from last UP state, not first non-UP state.
Example:
passive check, first_notification_delay set to 60, passive checks reporte=
d
every 5 minutes:
00 minute - reported OK
05 minute - reported OK - the last OK status
10 minute - reported DOWN - notification won't be sent (delay in progress=
)
65 minute - notification sent (55 minutes after DOWN, not 60)
70 minute - no notification sent
If passive checks are reported less frequent, e.g. one per our, things ge=
t
even worse.
Code snippet for ilustration of this behaviour:
/* checks viability of sending a host notification */
int check_host_notification_viability(host *hst, int type, int options){
[...]
if(type=3D=3DNOTIFICATION_NORMAL && hst->current_notification_num=
ber=3D=3D0 && hst->current_state!=3DHOST_UP && (current_time last_time_up=3D=3D(time_t)0L)?program_start:hst->last_time_up + (hst=
->first_notification_delay*interval_length)))){
log_debug_info(DEBUGL_NOTIFICATIONS,1,"Not enough time ha=
s elapsed since the host changed to a non-UP state (or since program star=
t), so we shouldn't notify about this problem yet.\n");
return ERROR;
}
Probably using "last_state_change" instead of "last_time_up" would be bet=
ter (haven't tried).
regards,
--=20
Pawe=B3 Ma=B3achowski
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]