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

Fri Dec 15 12:07:15 EST 2006

On Dec 12, 2006, at 5:43 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've been working on this all day and I think I may have a solution.
>
> Incidentally, I want to mention that if I add $! to the Link.pm warn
> line, I can see that there are two different types of ALERTs in
> error_log:
>
> Broken pipe
> Inappropriate ioctl for device
>
> Also incidentally, hitting F5 repeatedly always prints a few ALERTS in
> error_log, but the number of ALERTs printed seems to be about 10 times
> more for an http page than for the same page accessed via https.  I
> checked and tested the settings in my *:80 and *:443 vhosts trying to
> narrow that down, but I didn't come up with anything.
>
> Now, as I mentioned a few posts back, commenting out the html delivery
> stuff in the die_page sub of Link.pm eliminates the segfaults in
> error_log but not the ALERTs.  Today I enabled the prefork mpm in
> apache2 and tinkered with the Server/Child settings in interchange.cfg
> and httpd.conf and that did seem to reduce the ALERTs somewhat.
>
> After all of this, I've been browsing around my site and I haven't
> seen a single image or page fail to load like it used to.  The thing
> is, ALERTs still show up in error_log even for requests I'm sure I
> created myself AND WERE SERVED SUCCESSFULLY.  I hypothesize that the
> failed requests were because a $SIG{PIPE} was generated for whatever
> reason (although not because the user clicked the stop button), the
> html was delivered, it caused a segfault, and the request failed.  I
> should mention though, that if the failing request syndrome is fixed,
> it could also be from the apache2, httpd.conf, or interchange.cfg
> modifications mentioned above.  I doubt it though.
>
> Incidentally, I'd like to mention that the ALERTs can be generated
> pretty reliably by hitting the browser's stop button in the middle of
> a request, clicking on the same link again or a different link in the
> middle of a request (my Mom probably still double clicks links), or
> just refreshing the page in the middle of a request.
>
> If the failed requests do stop at this point, I think the die_page
> section of Link.pm is doing more harm than good.  Is there anything
> wrong with not handling $SIG{PIPE} at all?

Grant,

Shouldn't the $SIG{PIPE} be ignored at least? I don't know if there  
are implications for not handling it. Search perlipc manpage for PIPE.

--
Josh Lavin
Kingdom Design   http://www.kingdomdesign.com/