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

[dev.icinga.com #1579] retain status file over an init script reload #636

Closed
icinga-migration opened this issue May 23, 2011 · 8 comments
Closed

Comments

@icinga-migration
Copy link

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

Created by mfriedrich on 2011-05-23 20:50:06 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2011-06-08 11:24:55 +00:00)
Target Version: 1.4.1
Last Update: 2011-06-08 11:24:55 +00:00 (in Redmine)


even though this patch was against nagios 2.7 it could still be valid for the recent versions.

point is - event broker modules might still block the core on startup, like it happens with idoutils. but using the classic ui shouldn't be harmed by that. so the overall idea is to either make the neb module non blocking but the other one to just keep the status.dat over restart, not deleting it.

patch was done by opsview, attached.
http://labs.opsview.com/2007/09/nagios-patch-day/

It doesn’t delete the status file on a HUP signal. This gives the impression that Nagios is still running even though no new status information is being updated. We think this is acceptable – after all, CGIs are displaying the “latest” data, it just so happens that there is no update at this precise moment. The status file age doesn’t change, so nagiostat will show that the data is getting older, but it removes that scary screen

thing is - the cgis must check against the age of status.dat then. this can be taken out of icingastats code somehow (or check_nagios/icinga too).

i would make this behavior the default, and just allowing to disable it on demand.

Attachments

Changesets

2011-06-04 11:03:16 +00:00 by mfriedrich f6df030

core: fix retain status file over an init script reload #1579

refs #1579

2011-06-04 11:04:45 +00:00 by mfriedrich a46b9ba

core: fix retain status file over an init script reload #1579

refs #1579

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-05-23 20:51:34 +00:00

  • Category set to Status Data
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich
  • Target Version set to 1.5

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-05-24 14:26:30 +00:00

one thing to remark - the initscript should be aware of the status.dat location and delete that on a plain stop, but not restart/reload then. or handling that externally shouldn't happen either way.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-04 10:52:10 +00:00

the patch is as is is already within the core. the root cause is the init script itsself.

first off, the deletion of status.dat and icinga.cmd upon start and stop is wrong, this should be handled by the daemon (detecting the sigrestart).

secondary, a sigrestart is only detected by SIGHUP which is only true for /etc/init.d/icinga reload but not restart where stop and start are invoked, but not a SIGHUP being sent. so restarting the core itsself will cause the status.dat to be deleted either way. Issueing an icinga reload will keep the file as it was suspected to be.

maybe the cgis could check for actual data age in order to reflect long lasting reloads then, but that's another story.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-04 10:54:57 +00:00

  • Tracker changed from Feature to Bug
  • Subject changed from retain status file over a reload to retain status file over a init script reload

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-04 10:55:35 +00:00

  • Subject changed from retain status file over a init script reload to retain status file over an init script reload

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-04 10:55:45 +00:00

  • Target Version changed from 1.5 to 1.4.1

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-04 11:01:55 +00:00

i re-consider this a bug, so attached for r1.4 and 1.4.1 release.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-06-08 11:24:55 +00:00

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

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