[Nagiosplug-devel] Perf Data

[Karl DeBisschop]

On Tue, 2003-02-18 at 21:16, Richard Colley wrote:
> It would seem to me that relying on something like atomic write sizes is
> something of a hack.

<One Hand>

Practically speaking, the output has to be viewed on a web page. From
that point of view, 300 characters is pretty long anyway, unless you are
urlizing with a fairly long host name.

So I'm willing to have the restriction imposed. However if we do not
plan to change the pipes, then I'd want to code for it. At least in
urlize where truncation can cause html syntax errors.

</One Hand>

<The Other Hand>

Therein lies the rub. I don't think the plugin can code for it - it does
not know the length of the host/service name. So at best, that can only
be a guess. And if my quick scan of objects.h is correct, the
hostname/service can be arbitrarily long.

On this basis, I'm a little concerned. It has not been a big problem so
far. And we can take more care to ensure that output length is less than
about 350 bytes when --verbose is not specified.

</The Other Hand>

In the long run, I guess I don't like trusting to chance. Either
hostname/servicename should be limited in length so a dependable output
length calculation is possible, or we should implement something that is
more completely robust.

I don't want this to be too complex. I'd be quite happy to limit
overhead from name lengths.

--
Karl

> Maybe it is time to wrap the named external command pipe with an API that
> serialises messages into the pipe.
> 
> Also, a simpler way of fixing this issue for the internal non-named pipes
> from Nagios to children would be to have one pipe per child.  Given the
> number of children that would normally be active simultaneously, this
> shouldn't be a major issue.
> 
> Richard
> 
> 
> -----Original Message-----
> From: Ethan Galstad [mailto:nagios at nagios.org] 
> Sent: Wednesday, 19 February 2003 12:45 PM
> To: nagiosPlug Devel
> Subject: Re: [Nagiosplug-devel] Perf Data
> 
> 
> On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote:
> 
> > On Tue, 18 Feb 2003, Ethan Galstad wrote:
> > <snip>
> > >
> > > There are two pipes of interest.  One is the external command file,
> > > which is implemented as a FIFO and is restricted by the PIPE_BUF 
> > > limit (512 bytes minimum for POSIX).  Passive checks have to deal 
> > > with this limit, but not active checks.
> > > 
> > > The other pipe is used for IPC between the main (parent) Nagios
> > > process and the child processes.  Each child writes the results of a 
> > > plugin check (along with host/service name) to the pipe, at which 
> > > point the parent reads it and process it.  This pipe is also 
> > > restricted by the PIPE_BUF limit.  With host/service name overhead, 
> > > you're left with about 350 bytes useable for plugin output+perfdata.  
> > > It should be noted that *both* active and passive checks have results 
> > > sent through this pipe.  Passive checks enter through the FIFO and 
> > > then get dumped into this pipe.
> > > 
> > > If the size of the pipe becomes a real issue, we can probably break
> > > with POSIX compliance on most systems.  The POSIX standard states a 
> > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while 
> > > Solaris may have an 8K limit (I don't recall offhand).  I guess I'll 
> > > have to deal with it if and when it comes up.
> > > 
> > 
> > The second pipe - is that a single pipe per running install from the
> > temp_file var in the config file?
> > 
> 
> Its a single pipe, although its not implemented as a FIFO, so it 
> doesn't exist anywhere in the filesystem - just in memory.  You can 
> think of it as a very limited type of socket that you would 
> read/write from/to for network apps.  It has one reader (the parent 
> process) and multiple writers (the child processes).  Its implemented 
> with a call to pipe(2).
> 
> 
> 
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Nagiosplug-devel mailing list
> Nagiosplug-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003
>  
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Nagiosplug-devel mailing list
> Nagiosplug-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null