> >> > > 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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.