[dev.icinga.com #4430] External command to disable/enable freshness checking for specific hosts services #1314

icinga-migration opened this Issue Jul 19, 2013 · 8 comments


None yet
1 participant

icinga-migration commented Jul 19, 2013

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

Created by fruminator on 2013-07-19 12:47:33 +00:00

Assignee: (none)
Status: Resolved (closed on 2014-03-03 21:35:42 +00:00)
Target Version: 1.11
Last Update: 2014-03-03 21:35:42 +00:00 (in Redmine)

vis a vis: http://docs.icinga.org/latest/en/extcommands2.html

{DISABLE,ENABLE}_{HOST,SERVICE}_FRESHNESS_CHECKS already exist, but the disable/enable freshness checking at the entire system level.

Would be good to support disabling/enabling freshness checks for particular hosts services. Thus, propose adding the following commands, in the same vein as the commands to disable/enable passive checks for particular hosts/services.





2014-03-03 20:47:51 +00:00 by philmatu 62c72ea

External command to {en.dis}able freshness checks for hosts/services.

This patch enables commands to control freshness checking at both the
host and service level. Sometimes, it is necessary to implement
delayed notifications. In our case, passive notifications are being
sent from vehicles that leave the range of our wireless network coverage
area. When the vehicle leaves, we get a notification that the vehicle is
no longer reachable, but it should return within X hours. We wanted to
implement a delayed failure on only specific vehicles. By using freshness
checking, we wait for a passive check to come in saying the vehicle is gone,
then we enable a freshness check on that specific vehicle service and
change the current state to warning. If the vehicle is gone for more than
X hours, the freshness check will run automatically and change the state
to Critical. Hence, a delayed notification is now available. Furthermore,
this is useful with SNMP traps, where the trap may be sent several times,
but we want the first to be a warning, and the second trap to be a failure.

Refs #5422
Refs #4430

Signed-off-by: Michael Friedrich <Michael.Friedrich@netways.de>

2014-03-03 21:32:38 +00:00 by (unknown) 150e3db

Update Changelog/AUTHORS.

Refs #5422
Refs #4430

2014-03-03 21:33:23 +00:00 by (unknown) 90423a4

Merge branch 'feature/ext-cmd-freshness-5422' into next

Fixes #5422
Fixes #4430



icinga-migration commented Jul 19, 2013

Updated by fruminator on 2013-07-19 12:49:53 +00:00

This should be pretty straightforward. Just a matter of editing the commands.c file; practically a copy/paste job mimicking the way {DISABLE,ENABLE}_PASSIVE_{HOST,SVC}_CHECKS is implemented.


icinga-migration commented Jul 19, 2013

Updated by fruminator on 2013-07-19 12:52:21 +00:00

from some inspection of checks.c and events.c it does seem that all that needs to happen is changing the value of the check_freshness member of the relevant host/host_struct variable.


icinga-migration commented Jul 20, 2013

Updated by mfriedrich on 2013-07-20 10:41:03 +00:00

patches welcome.


icinga-migration commented Jul 27, 2013

Updated by mfriedrich on 2013-07-27 17:36:22 +00:00

  • Status changed from New to Feedback

icinga-migration commented Dec 19, 2013

Updated by philmatu on 2013-12-19 16:01:37 +00:00

Fruminator and I work for the same company. We have solved this problem with a workaround solution, that allows for the delayed response of passive checks (e.g. allowing for multiple SNMP traps, the first resulting in a warning, the second resulting in a critical state).

I created the patch as described but ran into a strange occurrence, freshness checking isn't a defined host or service field for the CGI status file or retention file, yet the web interface notified me of a modified freshness checking attribute in the core. After further digging, there is a modified attributes field, and an external command that allows the modification of this.

Although not as clear cut as I'd like, this is a much cleaner solution that doesn't require further development, since my patch would have required further reworking the status output files to maintain consistency in the source code across the core like the passive checking command maintains.

Therefore, the workaround is as follows (modeled on http://docs.icinga.org/latest/en/modified\_attr.html):

Enable Freshness checking:

Disable Freshness checking:

It is wise to obtain the previous value of the modification attribute (by parsing the status.dat file), then subtract or add 8192, since in our case, Passive checking (4) is also modified, so the value that we need to set and unset is 8196.


icinga-migration commented Jan 8, 2014

Updated by philmatu on 2014-01-08 21:18:14 +00:00

  • File added freshnesspatch.git

After further investigation, The MODATTR hack outlined above would only if the core was restarted every time this command was issues. Obviously, this won't work for our needs, so I've moved ahead with a patch that enables the following commands:



The commands are persisted across restarts using the MODATTR values, as outlined above, which are stored in the status.dat file, making no major modifications necessary to either this output/retention file, internal Icinga datastructures, nor the web interface (CGI). The patch allows for the existing global freshness checking functionality, meaning if ";<host_name>" is null, the global freshness checking will be altered (as it currently behaves in the master).

Attached is the patch that I have thoroughly tested against the master of Icinga-core. I'm hopeful that this can be integrated into the master.


icinga-migration commented Mar 3, 2014

Updated by mfriedrich on 2014-03-03 21:33:48 +00:00

  • Target Version set to 1.11

icinga-migration commented Mar 3, 2014

Updated by Anonymous on 2014-03-03 21:35:42 +00:00

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

Applied in changeset 90423a4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment