Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #584] Scheduled Downtime Notifications Resent On Restart/reload #284

Closed
icinga-migration opened this issue Jul 8, 2010 · 11 comments

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/584

Created by mfriedrich on 2010-07-08 16:18:03 +00:00

Assignee: ricardo
Status: Resolved (closed on 2010-09-23 06:48:15 +00:00)
Target Version: 1.3
Last Update: 2010-10-14 17:24:07 +00:00 (in Redmine)


http://tracker.nagios.org/view.php?id=124

     If a host/service is in scheduled downtime and the service is restarted/reloaded via "service nagios restart" or "service nagios reload", another DOWNTIMESTART notification is sent. 


Hi,

I have the same problem with nagios version 3.2.1.

Configuration :


System : Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Linux kernel version : 2.6.18-164.15.1.el5

Do you have more information about this bug ?


Regards,

Gregory Fardel

Attachments

Changesets

2010-09-23 06:40:45 +00:00 by mfriedrich 81eb1f3

fix scheduled downtime notifications resent on restart/reload #584

What happened here is, that a downtime is rescheduled after restart.
So it reads the status from the retention file, but it has no idea
if the downtime is already started or not. Because the flag
"is_in_effect" isn't stored to the status or retention data.

Added the flag to status and retention data.
Also to every function which is adding a downtime.

When icinga gets started then it will register and trigger a downtime
event soon after start, bailing also out on sending a notification if
downtime->is_in_effect is TRUE.

done by Ricardo.

fixes #584

2010-10-14 16:55:20 +00:00 by ricardo ddf93bb

corrected wrong implementation of fix #584 - re notification for downtime after icinga restart

Fixes #584 hopefully properly this time

Sorry for the wrong implementation.
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-07-09 14:41:56 +00:00

  • Category changed from Other to Notifications

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-08-06 18:09:38 +00:00

  • Status changed from New to Feedback
  • Priority changed from Normal to Low

base/notifications.c looks good.

code below should behave like expected. probably the counter is somewhat truncated? needs more feedback though.

/* checks the viability of sending out a service alert (top level filters) */
int check_service_notification_viability(service *svc, int type, int options){

...

        /* if this service is currently in a scheduled downtime period, don't send the notification */
        if(svc->scheduled_downtime_depth>0){
                log_debug_info(DEBUGL_NOTIFICATIONS,1,"This service is currently in a scheduled downtime, so we won't send notifications.\n");
                return ERROR;
                }

        /* if this host is currently in a scheduled downtime period, don't send the notification */
        if(temp_host->scheduled_downtime_depth>0){
                log_debug_info(DEBUGL_NOTIFICATIONS,1,"The host this service is associated with is currently in a scheduled downtime, so we won't send notifications.\n");
                return ERROR;
                }


and

/* checks viability of sending a host notification */
int check_host_notification_viability(host *hst, int type, int options){

...


        /* if this host is currently in a scheduled downtime period, don't send the notification */
        if(hst->scheduled_downtime_depth>0){
                log_debug_info(DEBUGL_NOTIFICATIONS,1,"This host is currently in a scheduled downtime, so we won't send notifications.\n");
                return ERROR;
                }

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-17 15:30:50 +00:00

  • Status changed from Feedback to Assigned
  • Assigned to set to ricardo

@ricardo

can you please have a look into that?

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-09-20 22:34:19 +00:00

  • File added notification_for_downtime_after_icinga_restart_fix.patch
  • Target Version set to 1.2 (Stable)

here the fix for the problem.

What happened here is, that a downtime is reschedule after restart. So it reads the status from the retention file, but it has no idea if the downtime is already started or not. Because the Flag "is_in_effect" isn't stored to the status or retention data.

Added the flag status and retention data. Also to every function which is adding a downtime.

And when icinga gets started then it will register and trigger a downtime event soon after start. Now following line takes effect:

    /* if downtime handler gets triggerd in between then there seems to be a restart of Icinga */
    /* Don't do anything just return */
    time(&current_time);
    if(temp_downtime->start_timeend_time && temp_downtime->is_in_effect==TRUE)
        return OK;

It dose the job for my test environment.

Can someone test this?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-21 13:02:13 +00:00

haha i bet this breaks livestatus too by changing add_downtime function. although the command sending is not an intended usage by taking livestatus as an api.

but i will apply and test, sure.

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-09-22 20:20:53 +00:00

as far as i could see, mk_livestatus isn't using any add_downtime function.

I didn't changed the broker_calls. We can leave it like it is and the modules won't get this variable. In this case no module have to be changed.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-22 20:45:10 +00:00

maybe we could make that an optional param somehow. but i think this flag is only used for internal functionality and shouldn't be reflected to the outside world.

thanks for testing once more, tomorrow = mfriedrich/core

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-23 06:46:21 +00:00

  • Priority changed from Low to Normal
  • Done % changed from 0 to 50

up in mfriedrich/core for testing.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-09-23 06:48:15 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 50 to 100

Applied in changeset commit:"81eb1f32ac379212b688b788e0000048af61583f".

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-10-13 21:34:40 +00:00

possibly related to this report?

http://www.nagios-portal.org/wbb/index.php?page=Thread&postID=137079#post137079

@icinga-migration
Copy link
Author

Updated by ricardo on 2010-10-14 17:24:07 +00:00

  • Target Version changed from 1.2 (Stable) to 1.3

sorry guys, another fix which hasn't worked properly.

Problem should be solved with commit: ddf93bb

I hate it when I try to fix something and brake other stuff. I'm really sorry.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant