NSCA using PROCESS_FILE

[Thomas Guyot-Sionnest]

On 01/03/07 01:54 AM, Hendrik Baecker wrote:
> Thomas Guyot-Sionnest schrieb:
>> 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.

Syslogd writes in non-blocking but doesn't keep data it can't write. The
only risk is a truncated line when the pipe fills up. I took a look at
the pipe and there's a small delay between each write (~100ms) so this
should never happen under normal operation with my daemon.

Maybe we should give more than one choice for pipes... In all cases it
should not block on open if there's no reader.

>> 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.

Indeed, I'm waiting for his input too :)


Thomas

-------------------------------------------------------------------------
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