Hi David,
----- Original Message -----
> On 05/13/2011 06:37 AM, Nathan Scott wrote:
> > Finally, I had some issues with the command-pipe mode of operation
> > in pmdalogger ... have you seen those David/Frank? Don't think I
> > broke that with my changes, but could be wrong there - we seem to
> > get EBADF always on a pipe fd read. PCP QA test 457 shows off the
> > issue, but a conf line like "pipe yes|" is enough to reproduce it.
>
> I looked at this last Thursday, but without much resolution.
>
> There is a problem with 457, since the bash script it runs does 'read
> book'. The way the pmdalogger code is written, those scripts won't
> have
> a valid stdin, so that 'read' will immediately return and the script
> will exit before 457 has a chance to send it the signal. The pipe'd
> process gets started with only 1 open fd - stdout (which of course is
> really our pipe).
Ah, of course.
>
> However, even with 457 changed to use 'while true; do sleep 1; done'
> to
> wait, I'm still not seeing the correct output from the test script.
> I'll continue to debug it.
Thanks! BTW, my dev tree is currently going to be failing several of
those tests, its a bit in-transition at the moment after the attempt
to move event_read out-of-line from the fetch code. I keep coming to
issues there, latest one is a relatively infrequent fetching client
causing memory use to blow out on the pmda because we keep all events
until we can hand them off.
Think we will need to introduce use of the "missed" events stuff and
start dropping some after a limit is reached, to try reign that in
(our production use case will see multiple gigabytes passing through
pmdalogger every hour, so I've gotta come up with something there).
cheers.
--
Nathan
|