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

Grant emailgrant at gmail.com
Fri Dec 15 12:35:43 EST 2006


> >> >> > 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.

I see the section you're referring to in the perlipc manpage, but I
don't know enough about perl to interpret it.

       Be careful to check both the open() and the close() return values.  If
       you're writing to a pipe, you should also trap SIGPIPE.  Otherwise,
       think of what happens when you start up a pipe to a command that
       doesn't exist: the open() will in all likelihood succeed (it only
       reflects the fork()'s success), but then your output will fail--spec-
       tacularly.  Perl can't know whether the command worked because your
       command is actually running in a separate process whose exec() might
       have failed.  Therefore, while readers of bogus commands return just a
       quick end of file, writers to bogus command will trigger a signal
       they'd better be prepared to handle.  Consider:

           open(FH, "|bogus")  or die "can't fork: $!";
           print FH "bang\n"   or die "can't write: $!";
           close FH            or die "can't close: $!";

       That won't blow up until the close, and it will blow up with a SIGPIPE.
       To catch it, you could use this:

           $SIG{PIPE} = 'IGNORE';
           open(FH, "|bogus")  or die "can't fork: $!";
           print FH "bang\n"   or die "can't write: $!";
           close FH            or die "can't close: status=$?";

- Grant


More information about the interchange-users mailing list