>> > The way my config works, apache2 hands all requests to the interchange >> > (icdevgroup.org) daemon via a socket by way of the mod_perl module >> > (Interchange::Link). >> > >> > So the error is caused by the mod_perl module trying to read or write >> > to or from the interchange daemon and failing? If that's correct, it >> > sounds like the next thing to do is find out why it's failing? Can it >> > be said whether it's a problem with mod_perl, Interchange::Link, >> > interchange, or something else at this point? >> > >> > 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.
It happens to me quite a bit as I browse my own site and I'm not hitting the stop button.
Add require Carp; Carp::cluck() to your die() function.
I should add: require Carp; to the top of the module with the other requires, and: Carp::cluck() on it's own line right before the warn line that includes the ALERT? - Grant
