> >> > >  Also, I tried restarting the interchange daemon with
> >> > >  PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> >> > >  frequently.  Does that tell us anything?
> >> >
> >> >
> >> >  It would make sense that, when you have high load, there is a problem
> >> >  processing many concurrent requests which triggers the PIPE signal, so
> >> >  you should find out what the error is, and handle it more gracefully.
> >> >
> >> >  You might want to change the die sub to print out $! and $? - that may
> >> >  give you a bit of a clue as to what caused the PIPE signal.
> >> >
> >> >  I'm guessing (and it is a guess) that the segfaults may be caused
> >> >  because the die sub sends a web response, but that sub could be called
> >> >  while your server is busy doing something else, and the two actions
> >> >  collide.
> >>
> >>  Very good guess.  Commenting out the web response stuff seems to have
> >>  eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> >>  getting one of these two bits along with each ALERT now:
> >>
> >>  Broken pipe 0
> >>  Inappropriate ioctl for device 0
> > This could happen from a Cntrl-C or stop in a browser.
> >
> > Add
> > require Carp;
> > Carp::cluck() to your die() function.
>
> Is this someplace that checking $r->connection->aborted() would be useful?

Would I just add "$r->connection->aborted()" without the quotes to the
warn line?

If I do change the warn line to:

warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $?
$r->connection->aborted()\n";

I get:

ALERT: bad pipe signal received for / Broken pipe 0
Apache2::RequestRec=SCALAR(0x16eef638)->connection->aborted()

Any help with that or Carp::cluck implementation would be greatly appreciated.

- Grant

Reply via email to