vanished bug numbers in the nagios mantis tracker
Andreas Ericsson
ae at op5.se
Wed Aug 8 14:05:05 CEST 2012
On 08/07/2012 11:09 PM, Jochen Bern wrote:
> On 08/07/2012 09:56 PM, Andreas Ericsson wrote:
>> The calling goes like this:
>> nagios -> modules: Modules, create your ancillary data!
> [...]
>> nagios -> modules: Modules, get your ancillary data!
> [...]
>
> (That's assuming that the ancillary data gets created/changed only at
> Nagios startup, or at least points in time that Nagios can somehow
> predict "close enough", whatever that may mean. Not my main point, but
> modules might receive external triggers of some sort, too.)
No, but it does require that the location of the pointers don't change.
If module A were to hand you a struct like this:
struct modA_ancillary_data {
struct host_worker **hwk;
size_t hwk_size;
struct service_worker **swk;
size_t swk_size;
};
it doesn't matter if hwk[35]->foo changes *value*, so long as the address
to hwk[35]->foo remains the same (note here that "foo" may well be a
pointer, in which case "changes value" means "points to a different
location"). So long as hwk[] is not reallocated it doesn't *matter* for
the reader that only modA writes to it.
>
>> At reload (or restart, or shutdown):
>> nagios -> modules: Modules, release everything that can't persist!
>> modules -> nagios: righto, releasing right away, SIR!
>
> Not quite what I tried to suggest, I'm afraid. Since the *actual*
> ancillary data is the modules' business, it's quite clear that it is
> also the (authoritative) module's business to *persist* *that*, if
> desired.
That's why "that can't persist" is tacked onto that sentence.
> However, this data is *bound to* a specific Nagios object
> through the ID provided by *Nagios*, and in order to correctly assign
> the ancillary data returning from the module's persistence layer, you
> need *either* the same level of persistence for the Nagios-provided ID
> numbers, *or* a (likely costly) means to re-identify all objects based
> on Lord knows what properties.
>
Nope. A reload is always identical in outcome to a full restart, so on
reloads all object related data is void and has to be recalculated the
next time we enter the event loop.
> (Specific example to clarify: Two hosts "foo" and "bar" in Nagios,
> currently with IDs 1 and 2. Module requests the ID numbers and assigns
> some sort of persistent ancillary data - say, it lets someone enter the
> hardware warranty's end date. Now the Nagios config is updated, a host
> "baz" is added, and the module wants to restore the persisted ancillary
> data to the *correct* hosts.
Which, I assume, are still located either in the object's config compound
or fetchable by some other means by the module. Am I correct? If so, no
persistence is necessary for objectrelated data.
> If the Nagios core does *not* provide that
> the original "foo" is *still* ID 1 and "bar" ID 2 afterwards (persistent
> IDs), the module would need to go out on a limb *guessing* that an
> unchanged hostname (IP, MAC, SNMP engine ID, dynamically IPMI-retrieved
> S/N, ... ?) indicates the intent of "that's still the same host".
Well, no. We could use hashes if that would make you feel better, with
the unique identifier of the object as the key to the hash. Modules with
data that's expensive to retrieve or calculate would most likely want to use
that in order to make reloads quicker. Assuming they want to go the extra
mile ofcourse. My guess is that they simply won't bother, or that they will
request core machinery to make their code run faster.
Hashes have a higher constant overhead, but they're still O(1) in terms of
asymptotic complexity, which tends to be what matters in huge networks.
> IMHO
> only *Nagios itself* is in a position to let the admin *explicitly
> state* his intent on the matter, by setting a global "bind_host_ids_to =
> host_name" option, if need be.)
>
Err, no. That's for the modules to decide, since they're the ones that know
what kind of data they'll be having or wanting. The 'id' variable shouldn't
even be settable by configuration. It will simply be assigned internally by
Nagios and will be determined based on wherever the object happens to end
up in a sorted array.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
More information about the Developers
mailing list