Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #2027] determine last_program_stop from creation of retention.dat and use that for decision if passive checks are fresh or not #772
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2027
Created by mfriedrich on 2011-10-22 14:51:21 +00:00
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 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