Hi Michelle,
On 19 Jun 2007, at 20:11, Michelle Craft wrote:
> It looks like it was changed because:
>
> http://article.gmane.org/gmane.network. ... evel/2438/
> match=passive+freshness+restart
>
>>> If the master is stopped for a
>>> long time and then restarted, the passive checks go stale at the
>>> next
>>> freshness cycle because there is not enough time for the slaves to
>>> send results back.
>
> - but nagios being down for a long time and having passive checks
> stale
> for awhile doesn't seem nearly as bad a problem as passive checks
> not ever
> becoming stale because of restarts.
I'm the original requestor of the change. My motivation was to reduce
the number of stale results in a distributed environment because it
"looks bad". I apologise for the unintended side effects.
Rather than another configuration parameter, can I propose this?
* If check_freshness_interval is defined, Nagios will use that
value and only check against the last_check_time. No "funny" stuff is
calculated
* If check_freshness_interval is not defined, then Nagios does a
calculation on the best value - currently it does things like using
check_interval, add latency time, lowers it if in a soft state. I'll
rework my change so that it raises the time if startup time is more
recent than last_check_time
So if you have a service you definitely want marked as stale after a
predefined period, use an absolute value (which logically makes sense
- if you want freshness, state the exact timeout period). Otherwise,
Nagios will try to calculate one which is optimised to a distributed
environment (which is the other major use case).
If there's a consensus to this, I'd be happy to make the change,
update the docs and post the patch here for approval. I'll even try
and add some tests so that this type of thing is flagged earlier.
Ton
http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]