[Nagiosplug-devel] Please can I have GIT access

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max wrote:
> On Tue, Sep 1, 2009 at 11:22 AM, Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
>> Back to the data retention debate, I agree if we go that way functions
>> could be used for state retention. Another thing we could consider
>> (although I believe you don't like it much) is shared memory...
> 
> Files in RAM or memcache is a lot easier to manage than shared memory.

Files in RAM means that you have to mount a tmpfs, so it's like plain
files. Regarding memcache, I don't really see the plugins requiring
it... It could be an option, but why not abstracting it in that case so
at least you don't have to link the plugins against a memcache library?

Anyway, see below why I don't like either of these method anyway...

>> Finally I believe there's another method that should be considered, and
>> although people are usually not very used to it it's pretty elegant
>> IMHO. Just open two file descriptors for the plugin to use, one for
>> reading in state and one for saving it. This could be done by Nagios
>> and, for older Nagios versions or passive checks, a simple wrapper could
>> be used to save the data to a file. Here's a Quick'nDirty(tm) example:
> 
> So FD 3 and 4 would be provided by Nagios to every plugin regardless
> of language?

Yes... Could be driven by a configuration directive too, because
otherwise nagios would have to provide the FDs either by creating the
files or mmap()ing some memory for them. A simple c wrapper could do it
as well with any desired storage (files, mmaped memory, shared memory,
memcached...).

This also have the advantage that the caller always determine the
storage location, which could avoid unexpected issues if more that one
Nagios instance runs the same checks or when a plugin is copied from
another server.

You have the same advantage when using performance data for state
retention BTW, but obviously the storage is much more limited.

 > Or are you still speaking here of an extension to do state for
> NRPE-hosted plugins?

That would work everywhere, either directly with proper support of the
underlying applications (Nagios, NRPE) or using a wrapper which as you
could see isn't very hard to do. Even a bash onliner can do it:
(touch file; /path/to/plugin 3<file 4>file.new; ret=$?; mv file.new
file; exit $ret)

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqdbxQACgkQ6dZ+Kt5BchZiTgCgl5pcOfdycD+ujw2v9gjRRs9h
/LsAmgOaOpGGHTXxw5Dq7c1goEvQTRWN
=tmDr
-----END PGP SIGNATURE-----