Bring host and service objects a little bit closer to each other

We do this by ironing out the differences between them, starting with
some that have no logical meaning what so ever.

services:
	last_notification     -> last_notification
	next_notification     -> next_notification
	obsess_over_service   -> obsess
	service_check_command -> check_command

hosts:
	last_host_notification -> last_notification
	next_host_notification -> next_notification
	obsess_over_host       -> obsess
	host_check_command     -> check_command

Unfortunately, we can't provide backwards compatibility macros for
the last_host_notification and next_host_notification macros,
since contacts have the same variables and it would ruin the build,
but these changes are non-invasive enough that mod authors should
be able to cope fairly easily.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2139 5f96b256-904b-4d8d-8c98-d829582c6739
lib/squeue: Make sure we work well on 32-bit systems

Previously on 32-bit archs gcc would issue the following warning:
	squeue.c:34:  warning: left shift count >= width of type

which is legitimate, because unless we explicitly cast the
return type we'll do math on 32-bit values, which clearly can't
be shifted 32 bits or more.

With this patch we break the math apart so we always operate on a
type large enough to support it. For those weird systems where
'unsigned long long' is not 8 bytes wide, we do our best by simply
using the 32 bits at our disposal to store the timestamp.

Reported-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@2140 5f96b256-904b-4d8d-8c98-d829582c6739
lib/dkhash: Don't oversize tables so enormously

For small inputs, rounding up to the nearest power of two seemed like
a sensible idea, when it quickly escalates the memory usage beyond
reasonable limits when we have, say, 1.1million objects (when we would
allocate 2^21 buckets for the hash table, ending up overallocating by
a *huge* amount).

With this patch we pay the 'modulo price' and let the caller decide
the size of the hash table, which should (for preference) be x1.5
of the number of objects one wishes to store in it.

While at it, we refactor the dkhash_create() routine a bit to make
it less deeply indented.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2141 5f96b256-904b-4d8d-8c98-d829582c6739
lib/skiplist: Doxygen document skiplist.h

... and remove the unused "skiplist_delete_all()" function.

Its current only use is to be called immediately by skiplist_delete()
and as such it's quite useless.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2142 5f96b256-904b-4d8d-8c98-d829582c6739
xdata/xodtemplate: Remove a lot of dead code

This removes the pretty ancient insertion sort algorithms used
prior to the addition of the skiplist libraries, which rendered
the former useless, as well as some of the timing values that
are no longer printed or even calculated.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2143 5f96b256-904b-4d8d-8c98-d829582c6739
Add some doxypages with technical documentation

The pages primarily list incompatibilities between Nagios 3 and 4,
but may well be used to house technical documentation later.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2144 5f96b256-904b-4d8d-8c98-d829582c6739
base/events: Remove double variable assignment

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@2145 5f96b256-904b-4d8d-8c98-d829582c6739
skiplist.h: Fix doxy comments

Apparently we missed the @file marker, so doxygen didn't parse it
after all.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2146 5f96b256-904b-4d8d-8c98-d829582c6739
common/objects: Reset object count before we read configuration

Otherwise some configuration types lead to bus errors when adding
or traversing objects.

This is a rework of a patch by William Leibzon, which fixed the
problem for the core but left it hanging for the CGI's.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2147 5f96b256-904b-4d8d-8c98-d829582c6739
core: Initialize service check result struct before calling modules

The earlier change (308a4221a62c67fdfd6aaa0b5bd6992896ca89dc, r1887)
had the intention of not setting the service as executing before we
called out to the module code, which was good, but we also changed
it to initialize the check result struct after the eventbroker
callbacks were made, which was bad.

This patch keeps the goodness and removes the badness, thereby
most likely fixing issue 350, though I haven't tested it.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2148 5f96b256-904b-4d8d-8c98-d829582c6739
macros: Don't export member macros to the environment in large installs

Doing so will quickly eat up the available environment space, which is
shared by environment variables and program arguments, and lead to
return codes of 127 for checks and notifications regarding hosts and
services in a group with enough members with enough long name that a
comma-separated list of all member names consume too much of the
available (usually 128kbytes) memory reserved by the kernel for
program arguments and environment variables.

Users that desperately need that information will have to pass it
as command line arguments instead, and just keep their groups small
enough that their members and everything else can fit in the limited
memory the kernel gives us.

This provides an easy workaround for issue 354.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2149 5f96b256-904b-4d8d-8c98-d829582c6739
Make current state logging on log rotation configurable

It can cause an ungodly amount of spam in the logfiles, so we make
it configurable.

This patch was sent to the nagios tracker by one "awiddersheim",
but seems to have originally been coded up by one "ricardo". I'm
not sure, but I believe that's Ricardo Maraschini.

Issue #371 is hereby fixed.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2150 5f96b256-904b-4d8d-8c98-d829582c6739
common/macros: Return a nul string for empty host and servicegroups

Contactgroups seem to be handled differently, so perhaps they don't
matter.

This fixes issue 358, although not in the way the reporter suggested.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2151 5f96b256-904b-4d8d-8c98-d829582c6739
core: Avoid scheduling stuff a week into the future

One pretty major issue with scheduling one week into the future is
that by next week the time will be exactly the same as it is now,
so if timeperiods are defined in a "normal" manner we'll be in the
exact same situation then as we are now, and we'll just keep on
scheduling stuff far into the future.

Another issue is that it's unlikely that checks are actually
supposed to run that far into the future, and we can therefore
assume that things have gone haywire beyond the usual manners.

The most sensible (for a given value of sensible) thing we can do
is to use the preferred time to schedule the check and see then
if we can get a sane timeslot for the check to run. That will
cause us to run into the event more frequently than necessary,
but it's not that great a chore and it will at least prevent
checks from going awol in scheduling limbo for any extended period
of time.

As a nice bonus, it also lets me close issue 31 for good and all,
as users now have a way to tweak the amount of time into the
future we'll schedule the checks when we fail to schedule them
due to some bugs, which is a Good Thing(tm) indeed and lets them
work around future problems by using some suitable number for
check interval. So long as it's shorter than the configured time
period slot, the check is guaranteed to run at least once.

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

git-svn-id: https://nagios.svn.sourceforge.net/svnroot/nagios/nagioscore/trunk@2152 5f96b256-904b-4d8d-8c98-d829582c6739
core: Remove reaper frequency hints from scheduling recommendations

Since we use worker processes, the check_result_reaper_frequency
variable only matters if addons are dropping check results in Nagios'
spool file directory, which we don't expect will happen so often that
the check_result_reaper_frequency actually matters one whit.

Signed-off-by: Andreas Ericsson <ae@op5.se>
core: Create scheduling queues when testing scheduling

It's needed to avoid getting a bazillion errors from initializing
the event loop.

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