Skip to content
This repository has been archived by the owner. It is now read-only.

[ #2027] determine last_program_stop from creation of retention.dat and use that for decision if passive checks are fresh or not #772

icinga-migration opened this issue Oct 22, 2011 · 1 comment


None yet
1 participant
Copy link

commented Oct 22, 2011

This issue has been migrated from Redmine:

Created by mfriedrich on 2011-10-22 14:51:21 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2011-11-11 17:02:35 +00:00)
Target Version: 1.6
Last Update: 2011-12-03 11:30:20 +00:00 (in Redmine)

since we know that retention.dat is being written on shutdown of the core, we can easily read the creation_time and determine the last shutdown, indicating that icinga stopped that time.

while the current calculation on freshness of check results does not know when icinga stopped the last time, but only uses last_check and a freshness threshold to determine the expiration_time - which would spit quite a lot into syslog if the core was shutdown for a longer period of time than the actual last_check plus freshness_threshold would be calculated.

now, if a check is passive and the checkresult is checked if fresh,

  • event_loop start (event_start, MACRO_EVENTSTARTTIME) happened within range program_start + 60 seconds - could be a problem with config dump in idoutils!


  • event_loop start - last_program_stop = difference how long icinga has been shutdown. if this is below a heuristic percentage of 61,8% of the freshness_threshold we can say that the expiration_time changes to

event_loop start plus freshness_threshold, saving us a longer timewindow where checks are determined not stale on startup - but only IF icinga was shutdown not longer than 61,8% of the threshold time.

this could be tricky on longer lasting startups, especially what happens between programstart and eventloopstart (idomod config dump, status updates from retention.dat) and could probably not being hit.

until we resolve the idoutils problems, we keep this implementation for those using the core only, e,g, on a distributed master/slave setup or an a failover setup.

if there is no retention.dat - creation_time is 0L, last_program_stop is 0L, condition is not matched because event_start minus 0L cannot be larger than freshness_threshold 61,8%, so not triggered and old functionality fully intact).


2011-10-22 14:52:24 +00:00 by mfriedrich c876029

core: determine last_program_stop from creation of retention.dat and use that for decision if passive checks are fresh or not (Andreas Ericsson) #2027

please check the issue for deeper analysis and description.

refs #2027

This comment has been minimized.

Copy link
Member Author

commented Nov 11, 2011

Updated by mfriedrich on 2011-11-11 17:02:35 +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.
You can’t perform that action at this time.