[ic] Re: ALERT: bad pipe signal received for /page.html

Ron Phipps ron at endpoint.com
Mon Dec 11 18:35:13 EST 2006


Josh Lavin wrote:
> On Dec 11, 2006, at 12:42 PM, Ron Phipps wrote:
>> Josh Lavin wrote:
>>> On Dec 11, 2006, at 12:02 PM, Grant wrote:
>>>>> > Hello, I've been plagued by apache2 segfaults ever since I started
>>>>> > using Interchange::Link years ago.  The latest Link.pm has ALERT
>>>>> > messages accompanying the segfaults in error_log:
>>>>> >
>>>>> > ALERT: bad pipe signal received for /page.html
>>>>> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal
>>>>> > Segmentation fault (11)
>>>>> >
>>>>> > Does anyone have any advice on solving this?  I'm using 
>>>>> apache-2.0.58
>>>>> > and mod_perl-2.0.2 in Gentoo Linux.
>>>>>
>>>>> Also, here is the portion of Link.pm that the ALERT seems to come 
>>>>> from:
>>>>>
>>>>> # Return this message to the browser when the server is not running.
>>>>> # Log an error log entry if set to notify
>>>>>
>>>>> sub die_page {
>>>>>
>>>>>     my $r = shift;
>>>>>     my $msg;
>>>>>
>>>>>     warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n";
>>>>>
>>>>>     $r->content_type ("text/html");
>>>>>     $r->print (<<EOF);
>>>>> <HTML><HEAD><TITLE>Interrupted</TITLE></HEAD>
>>>>> <BODY BGCOLOR="#FFFFFF">
>>>>> <H3>Someone pressed stop...</H3>
>>>>> <P>
>>>>> We have aborted this request because someone terminated it.
>>>>> Please try again soon.
>>>>> </BODY></HTML>
>>>>> EOF
>>>>>
>>>>> }
>>>>>
>>>>> Please let me know if you have any ideas.
>>>>
>>>> The segfaults are eliminated by commenting out the $r stuff in the
>>>> die_page sub.  I still get the ALERTs though.  Does anyone have any
>>>> advice on figuring out why I'm having the bad pipe problem?  Is there
>>>> an easy way to add extra debugging info to the sub?
>>>>
>>>> Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs 50 
>>>> fold.
>>> I've been seeing this too, on my Apache 2 and latest Link.pm. I also 
>>> had to use PERL_SIGNALS=unsafe and so I get quite a lot of these.
>>> The visible effect on the browser is that the page or image (which 
>>> Link.pm apparently still has some part in delivering) does not load. 
>>> I get them myself when browsing and testing my websites, and I have 
>>> never stopped loading a page or had any other problems on non-IC 
>>> sites I host.
>>> I was told the problem stems from either the browser and a stop 
>>> button or some other network fault. I may go back to Apache 1.3 to 
>>> get around this.
>>
>> I saw this occur on two different installations about 4 months ago.  
>> It was suggested that I abandon the use of Link.pm and go back to 
>> using the cgi method with URL rewrite rules as this was just as fast 
>> and proved stable over the years.
> 
> Is plain CGI really as fast as mod_perl or mod_interchange? That'd be my 
> only concern with switching back to CGI+rewrites.
> 
> Maybe it is ok -- see mod_interchange's README:
> 
> "The Interchange link protocol has been
> implemented via an Apache module which
> saves us the (small) overhead
> of the execution of a CGI program."
> 

Josh,

I have not done any a/b tests to determine which is faster, others have.

Vlink/tlink is currently being used without any speed issues during high traffic periods at:

www.bcstore.com
www.frozencpu.com
www.citypass.com
www.reliablemedical.com

Quite a bit of time was put in with BCStore to compare which method was stable and fast and it was determined that tlink/vlink was the way to go.

I thought that we needed to use mod_interchange/mod_perl for FrozenCPU, but quickly found out that under Apache 2.0/mod_perl the issues far outweighed any perceived speed up.  tlink/vlink are compiled c programs and should be very quick in execution.

At End Point we use rewrites with tlink/vlink pretty much exclusively.

Thanks,

-- 
Ron Phipps
End Point Corporation
ron at endpoint.com


More information about the interchange-users mailing list