NSCA using PROCESS_FILE

Hendrik Baecker andurin at process-zero.de
Thu Mar 1 07:54:24 CET 2007


Thomas Guyot-Sionnest schrieb:
>> -----Original Message-----
>> From: nagios-devel-bounces at lists.sourceforge.net 
>> [mailto:nagios-devel-bounces at lists.sourceforge.net] On Behalf 
>> Of Thomas Guyot-Sionnest
>> Sent: February 28, 2007 8:25
>> To: Nagios Developers List
>> Subject: Re: [Nagios-devel] NSCA using PROCESS_FILE
>>
>> I just checked on a host I'm building and apparently Nagios doesn't
>> block on full pipe. So far I haven't had any dieing daemon 
>> problems either.
>>     
>
> Eh, I just realized my test could have been wrong... I restarted Nagios and
> did an strace and yes, it won't block. However it won't write anything
> either:
>
> write(5, "[SERVICEPERFDATA]\t1172678948\t10."..., 58) = -1 EPIPE (Broken
> pipe)
>
>
> I'd like to see a option for pipes that would show the same behavior as
> syslogd: fill the pipe, and don't block when the pipe if full. This mean we
> won't loose data if the daemon is temporally down. Here's an example of
> syslogd at work:
>   
Oh, warning! Do you know what happens with the data if the pipe is full
and write see this EAGAIN?
AFAIK it is up to the writing application to cache the data to write
them to the pipe after it is re-established.
If it so, nagios might ran into evil memory eating if it has to cache
the data.
There might be a way to write data to a regular file if write to the
pipe fails. After examine that the pipe is back to OK State nagios has
to read out the missed data and push them to the pipe.
> Writing to a non-full pipe:
> writev(4, [{"Feb 28 11:13:03", 15}, {" ", 1}, {"hostname", 8}, {" ", 1},
> {"root: test", 10}, {"\n", 1}], 6) = 36
>
> Writing to a full pipe:
> writev(4, [{"Feb 28 11:12:08", 15}, {" ", 1}, {"hostname", 8}, {" ", 1},
> {"root: test", 10}, {"\n", 1}], 6) = -1 EAGAIN (Resource temporarily
> unavailable)
>
> Since writev should behave just like write I assume the difference is on the
> file filehandle flags. The *_perfdata_file_mode= parameter could be used to
> trigger this behavior, ex: "service_perfdata_file_mode=p".
>
> Any chance this gets in in CVS HEAD? In 2.x? I could try to make a patch is
> it can help, this seems like a trivial change to make it work.
>   
Before this I would like to know what Ethan is thinking about this.

Ethan?

Regards
Hendrik

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV




More information about the Developers mailing list