So the problem centres around this bit of code in nagios.module on 6.x:
nagios.module - lines 398 - 417
$severity = REQUIREMENT_OK;
$min_severity = variable_get('nagios_min_report_severity', NAGIOS_STATUS_WARNING);
foreach ($reqs as $key => $requirement) {
if (isset($requirement['severity'])) {
// Ignore update_core warning if update cache has expired and nagios_cron_duration has not passed by yet
if ($key == 'update_core' && $requirement['severity'] == REQUIREMENT_WARNING && $requirement['reason'] == UPDATE_UNKNOWN) {
$grace = 60 * variable_get('nagios_cron_duration', 60);
$expire = db_result(db_query("SELECT expire FROM {cache_update} WHERE cid = '%s'", 'update_available_releases'));
if ($expire && time() < ($expire + $grace)) {
continue;
}
}
if ($requirement['severity'] >= $min_severity) {
if ($requirement['severity'] > $severity) {
$severity = $requirement['severity'];
}
$descriptions[] = $requirement['title'];
}
}
}
So on 398, the severity is set to OK - a sensible default. The module then checks the requirements for updates, and loops over them.
The issue is that if the site is only looking for core updates (or only requires core updates), for the duration that time() is less than $expire + $grace (which defaults to 60 minutes), the severity is not reset due to the continue; on the loop, resulting in a false OK status being returned.
Comments
Comment #1
instanceofjamie commentedAttached is a patch to cache the previous state and display that if we're in an unknown state. Alternatively, we could just ignore the grace period, though it's probably more healthy to let updates run before we display any, and assume that the previous state is the correct one, until it isn't.
Comment #2
instanceofjamie commentedComment #3
greg.harveyWorks for me, will commit.
Comment #4
instanceofjamie commented\o/
Comment #5
greg.harveyCommitted to Drupal 6 branch, need a Drupal 7 port of this.
Comment #6
morenstratHm, I don't understand the purpose of this patch. It breaks the changes that were introduced in #615128: warning issued when update status check fails.
It also creates the following error when fetching update information is pending:
Comment #7
instanceofjamie commentedHi dunix,
The point of this patch is for this scenario:
We have a site that requires updates - Nagios has a CRITICAL state showing, and our bot announces it in IRC. Some hours later, the update cache runs out, and it's time to re-query the update status info from drupal.org, so there's a wait of up to an hour before that happens again. During this wait time, Nagios returns an OK state, and then flips back to CRITICAL once it's updated from drupal.org.
The intention of this patch is purely to remember the previous nagios state as it's recorded, and if we can't find update status information, to display the previous state rather than an OK state.
I'm slightly worried that I've missed something, though. Would you expect a state change to happen in this case? In our case, I think I'd rather assume the state's the same (ie - CRITICAL because we haven't yet upgraded) until we've checked against drupal.org.
The error on the join is likely to be due to $descriptions not having been initialised in the prior loop, due to - that's simple enough to patch.
-- Jamie
Comment #8
morenstratHi Jamie,
ah, I see, makes sense. But I think the cache_set calls are at the wrong position. Currently, they do not necessarily store the update_core requirement. I attached a patch for the 6.x-1.3 release.
Dunix
Comment #9
helmo commentedI also noticed this in the D7 version... here's an updated patch.
Comment #11
greg.harveyDrupal 6 patch didn't apply, but since it's out of support and wasn't a particularly robust feature for D6 anyway, I'll let it slide.
Drupal 7 patch applied cleanly and is now in the dev snapshot at last! \o/
Needs investigation to see if this cache bug will also affect Drupal 8 websites.
Comment #12
greg.harveyOops, db_result() is obsolete in Drupal 7, didn't spot that in helmo's patch. New patch!
Comment #14
greg.harveyThis worked on simplytest.me, so applied it.
Comment #15
gogowitsch commentedWith Drupal 8 I didn't observe this on any of our sites. I'll mark it as fixed for now. Feel free to re-open or add a new issue if you run into it again.