New tool for testing downtimes

The test-downtime.pl script will test the Nagios Core downtime
functionality. It does so completely outside of Core and can use
either active or passive service checks for its tests. The script
runs through every reasonable permutation of downtime starts and 
ends, Nagios starts and stops and service failures and recoveries.


git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2501 5f96b256-904b-4d8d-8c98-d829582c6739
notifications: Fix first_notification_delay

Nagios bug #297, while being light on details, points out a problem with
first_notification_delay that I think this patch clears up.

The problem is two-fold: first, the logic for finding out which state to
use is incorrect - a comment rightly points out that last_time_{ok,up}
is the wrong value to use, and then proceeds to use any value that is
both more recent and less recent than last_time_{ok,up} - this condition
is likely to fail, meaning we always use the incorrect value.

Second, the logic is impossible to correct, though, because all the
other values are incorrect, too - we always set last_time_$state
whenever a check is executed, meaning the problem last_time_$state
variable would usually be too recent.

This is fixed by redefining last_time_$state. They used to be "the last
time a check returned $state", now they're "the last time an object was
in $state". The change is subtle, and the value is usually updated the
way it was before, but when the state changes, we put the end time of
the previous state in last_time_$previous_state, rather than putting the
start time of the current state in last_time_$current_state. Nagios core
does not use these variables anywhere else, and it's unlikely to break
other peoples code, since last_state_change is a much better way to get
the start time of the current state.

With this change in place, all we need to do to find out when a problem
began is to read last_time_{ok,up}, use that to compare against
first_notification_delay, and we're done.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2502 5f96b256-904b-4d8d-8c98-d829582c6739
common/objects: Remove stray newline from cached contact objects

Why that line was there I'll likely never find out...

Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2503 5f96b256-904b-4d8d-8c98-d829582c6739
xod: Make group member parsing work with precached objects

This caused all manner of weird bugs, such as hostgroups being
empty and notifications not being sent out to contacts added to
contactgroups which in turn were set to be assigned to certain
hosts and services, but only when using precached objects, which
is how this slipped through the testing net.

With this patch the objects.precache is identical to the
objects.cache file generated from it after Nagios has parsed it,
with two exceptions:
 * The date/time thing will obviously differ.
 * All lists are printed in reverse order in objects.cache

The date thing I won't even bother commenting on. Just live with
it. The reverse order thing might be a bit of an issue though,
but since member lists aren't sorted in either file (and won't be
if Nagios is started without using a precache file) anyway, I
really don't care about that either.

Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2504 5f96b256-904b-4d8d-8c98-d829582c6739
base/logging: Handle case where log file can't be opened better

When log file couldn't be opened, nagios would try to print a message to
STDOUT, and then segfault. You could say that gets the point across, I'd
say it's unnecessarily brutal.

This patch sends nagios back to work instead, skipping the logging.
Maybe the log file error will sort itself out once a flaky connection
has restabilized, maybe it won't and nagios'll notice and send out a
notification, maybe other means of logging is in use.

Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2505 5f96b256-904b-4d8d-8c98-d829582c6739
core: Drop privileges before checking if nagios binary is executable

Doing it before we drop 'em won't catch the case where the binary
is executable for root but not for the Nagios user.

Patched-by: Ricardo Maraschini <ricardo.maraschini@opservices.com.br>
Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2506 5f96b256-904b-4d8d-8c98-d829582c6739
core: Make sure we managed to grab nagios_binary_path

Not checking the return value here will cause a coredump later in
case we didn't get the memory we asked for. If we didn't, there's
not much point going on anyway, since we'll be getting ENOMEM all
over the place when parsing object configuration.

Patched-by: Ricardo Maraschini <ricardo.maraschini@opservices.com.br>
Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2507 5f96b256-904b-4d8d-8c98-d829582c6739
core: Make perfdata and status files nagios.cfg-relative

For most people this won't matter in the slightest, as most people
already have absolute paths for them, but it's nifty for testing
and makes path resolution consistent with the ones parsed in config.c.
Since where we parse a variable is an implementation detail that we
can't expect users to be aware of, this should probably be considered
a bugfix, although in reality it's more like a feature extension.

Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2508 5f96b256-904b-4d8d-8c98-d829582c6739
core: Use nagios.cfg-relative paths when locating broker modules

We do it for everything else (or so I hope), so it makes sense to
do it for these too.

Signed-off-by: Andreas Ericsson <ae@op5.se>

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2509 5f96b256-904b-4d8d-8c98-d829582c6739