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

Mon Dec 11 18:16:37 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 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.
> >> >
> >> > The problem with the cgi method is it requires your pages to have a
> >> > URL that includes the catalog name.
> >>
> >> That is simply not true.
> >>
> >> Bye
> >>         Racke
> >
> > Are you referring to mod_rewrite?  mod_rewrite will only change what
> > appears in the address bar right?  I need something that allows IC to
> > generate folder-free URLs.  Can IC be configured to generate and use
> > such URLs via the cgi method?
>
> Look into the FullURL directive. This allows you to specify your Catalog like that:
>
> Catalog linuxia /home/racke/linuxia www.linuxia.de www.linuxia.de:443
>
> Now you have only to ensure that the calls from the clients are passed on to
> IC, e.g.:
>
> Alias /images/ /home/racke/linuxia/html/images/
> ScriptAliasMatch ^/(.*)$ /usr/lib/cgi-bin/ic/linuxia/$1
>
> You can also use rewrite do achieve that.

Thank you Racke, I'll check that out.  Interchange::Link doesn't seem
to be curable.  Maybe it's a limitation of mod_perl?

- Grant