Re: HTTP and MPM support

[William A Rowe Jr]

On Fri, Jan 25, 2019 at 11:35 AM John Dunlap  wrote:

> I'm in the process of optimizing our web application for performance and
> one thing that I was really excited to try was mod_http2 because it allows
> the browser to send multiple requests through the same TCP connection with
> compressed headers. However, when I enabled it and restarted apache I was
> greeted with this:
>
> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The
> mpm module (prefork.c) is not supported by mod_http2. The mpm determines
> how things are processed in your server. HTTP/2 has more demands in this
> regard and the currently selected mpm will just not do. This is an advisory
> warning. Your server will continue to work, but the HTTP/2 protocol will be
> inactive.
>

To this question, the answer should be blatantly obvious; http2 doesn't
simply support multiple requests (connection: keepalive solved that)
but supports parallel requests. This clearly isn't compatible with any
single-threaded/single-worker per connection strategy.

A hybrid mod_prefork could be coded to dispatch all worker requests
across to distinct worker processes for a single connection, but I
don't anticipate anyone interested in doing such development.


> The last time I tried to use either mpm_worker or mpm_event my application
> was plagued by seemingly random segfaults. Are there any plans to support
> other MPM's? If not, the benefits of HTTP2 appear to be permanently out of
> reach for our mod_perl applications and that, honestly, might force us into
> seriously reevaluating our technology stack. :(
>

Your compatibility with the worker MPM is likely much stronger than
with the event MPM; however... all request workers can behave in a
"free threaded" manner under mod_http2, eliminating the relative
simplicity of the worker MPM. Working out each and any of these
specific segfaults occurs is the only way to improve the situation.

For the general mod_perl activity to increase, the Apache Perl Project
needs active volunteers and contributions. Consider this entire thread
an open invitation to participate.

Re: Upgrading a mod_perl application from Apache 2.2 to Apache 2.4

[William A Rowe Jr]

On Thu, Dec 6, 2018 at 3:34 PM Andrew Green  wrote:

> Hi William,
>
> But you are better off looking at;
>
> http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html#C_get_server_version_
>
> which returns nothing except exactly what you are asking.
>
>
> I did try this (and it worked fine) — but I kept seeing the following
> error pop up in the logs:
>
> *ap_get_server_version() is deprecated since httpd/2.3.0 try using
> ap_get_server_(description|banner)() instead*
>
> So I switched to banner.  I’ll see about switching again to description.
>

Ahhh, ok, just be aware the get_server_description call doesn't exist in
2.2, you need
to perform a little eval() magic to guard against that expected failure.

Re: Upgrading a mod_perl application from Apache 2.2 to Apache 2.4

[William A Rowe Jr]

On Thu, Dec 6, 2018 at 9:25 AM Andrew Green  wrote:

> Hi all,
>
> Huge thanks to everyone for your replies on this.  I’ve now been able to
> work through everything, and I thought I’d post a quick update with some
> additional notes in case there’s anyone else in the same boat searching the
> archives in the future!
>
> 1. I was able to use the following as a way of determining which version
> of Apache is in use at runtime:
>
> my $server_version = Apache2::ServerUtil::get_server_banner();
> my $is_old_apache = ($server_version =~ /Apache\/2\.2/) ? 1 : 0;
>

Just a little warning, the server_banner is controlled by the admin, and
may not include
the entire Apache/2.2 token. The server_description fleshed this out beyond
the control
of the admin, but isn't meant for transmission;

/**
 * Get the server banner in a form suitable for sending over the
 * network, with the level of information controlled by the
 * ServerTokens directive.
 * @return The server banner
 */
AP_DECLARE(const char *) ap_get_server_banner(void);

/**
 * Get the server description in a form suitable for local displays,
 * status reports, or logging.  This includes the detailed server
 * version and information about some modules.  It is not affected
 * by the ServerTokens directive.
 * @return The server description
 */
AP_DECLARE(const char *) ap_get_server_description(void);

But you are better off looking at;
http://perl.apache.org/docs/2.0/api/Apache2/ServerUtil.html#C_get_server_version_

which returns nothing except exactly what you are asking.

Re: CPAN will shutdown

[William A Rowe Jr]

On Tue, May 22, 2018 at 10:41 PM, Practical Perl 
wrote:

> *search.cpan.org  is shutting down*
> For details read Perl NOC
> .
> After June 25th this page will redirect to MetaCPAN.org
> 
>
>
> So does as well as Perl?
>

In this day and age, seamless delegation is so trivial, but I was heartened
to read;

*"Update #1 (2018-05-19)*:  There's some confusion around whether or not
existing search.cpan.org URLs will continue to work.  They will!  The vast
majority of of them will be transparently served by MetaCPAN pages.  You do
not need to update any links right now."

Provided that eases away 95% of maintenance headaches, it seems sysadmins
and users all get to have our cake.

Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)

[William A Rowe Jr]

Yes, that's an artifact of the phase in which we handle the remoteip
transposition. It could be slightly earlier which is why I raised the
question to the httpd dev community.

On Tue, Mar 14, 2017 at 12:31 AM, JW <gav...@yahoo.com> wrote:
>
> Don't know the answer to your question about remoteip ...
>
> However, what I noted is that the Apache remoteip module,
> when configured with "RemoteIPHeader X-Forwarded-For", deletes the
> X-Forwarded-For header.
> In the PerlPostReadRequestHandler stage, the X-Forwarded-For header
> exists and it seems Apache has yet to use the X-Forwarded-For value as
>  $r->useragent_ip gives 127.0.0.1.
> In the next stage, PerlTransHandler, a call to $r->useragent_ip() gives the
> correct remote ip, but the X-Forwarded-For header is no longer available.
>
>
> 
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: httpd <d...@httpd.apache.org>; modperl@perl.apache.org
> Cc: JW <gav...@yahoo.com>
> Sent: Monday, March 13, 2017 4:53 PM
>
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> This has occurred in multiple contexts, including throwing segfaults in the
> modperl test framework (connection handler, so no req_rec.)
>
> Wondering if remoteip might be able to run a little bit earlier? This is all
> relevant to what we are discussing about PROXY protocol enhancements.
>
> On Mon, Mar 13, 2017 at 6:28 PM, JW <gav...@yahoo.com> wrote:
>> 
>> From: William A Rowe Jr <wr...@rowe-clan.net>
>> To: JW <gav...@yahoo.com>
>> Cc: "modperl@perl.apache.org" <modperl@perl.apache.org>
>> Sent: Friday, March 10, 2017 1:44 PM
>> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>>
>> On Thu, Mar 9, 2017 at 9:53 PM, JW <gav...@yahoo.com> wrote:
>>>
>>> It's been over a month since moving to Apache 2.4. It was fairly
>>> straightforward and required
>>> little code to be updated, most of it Apache config. Everything runs as
>>> it
>>> did before the update and I've
>>> had no problems. The one function that didn't 'work' is described below.
>>>
>>> This mod_perl server is behind a proxy on the same machine. Under Apache
>>> 2.2, $r->remote_ip()
>>> returned 127.0.0.1 and not the user's actual IP.  So, a
>>> PerlPostReadRequestHandler extracted the user's
>>> IP address from the X-Forwarded-For header and set it with $r->remote_ip(
>>> $ip ).
>>>
>>> In Apache 2.4 (and mod_perl now) $c->remote_ip is split into
>>> $r->useragent_ip and $c->client_ip:
>>> http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>>> But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be
>>> fixed
>>> at some point (unless
>>> I'm doing something wrong). So, for now, as above, the IP is extracted
>>> from
>>> X-Forwarded-For
>>> and set with $r->useragent_ip( $ip ).
>>
>>
>> Keep in mind you can't use r->useragent_ip until the request is created,
>> e.g.
>> the create request hook is not a good place to try this (we actually had
>> to
>> work around a crash related to this behavior in httpd's sources.) After
>> the
>> read_request phase, this information will be finalized (provided that the
>> mod_remoteip config is correct).
>>
>> It seems some code was expecting to read the useragent_ip in a very early
>> phase of connection handling, although the headers to populate it for the
>> request had not even been read off the wire :) So now, all attempts to
>> read
>> this too-early will result in the c->client_ip values.
>>
>> Here's when the action happens;
>> ap_hook_post_read_request(remoteip_modify_request, NULL, NULL,
>> APR_HOOK_FIRST);
>
> Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
> gives the remote ip with the PerlTransHandler and later stages. Thanks!
>
>

Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)

[William A Rowe Jr]

This has occurred in multiple contexts, including throwing segfaults in the
modperl test framework (connection handler, so no req_rec.)

Wondering if remoteip might be able to run a little bit earlier? This is all
relevant to what we are discussing about PROXY protocol enhancements.

On Mon, Mar 13, 2017 at 6:28 PM, JW <gav...@yahoo.com> wrote:
> 
> From: William A Rowe Jr <wr...@rowe-clan.net>
> To: JW <gav...@yahoo.com>
> Cc: "modperl@perl.apache.org" <modperl@perl.apache.org>
> Sent: Friday, March 10, 2017 1:44 PM
> Subject: Re: Question about Apache 2.4 and libapreq2 (Apache2::Request)
>
> On Thu, Mar 9, 2017 at 9:53 PM, JW <gav...@yahoo.com> wrote:
>>
>> It's been over a month since moving to Apache 2.4. It was fairly
>> straightforward and required
>> little code to be updated, most of it Apache config. Everything runs as it
>> did before the update and I've
>> had no problems. The one function that didn't 'work' is described below.
>>
>> This mod_perl server is behind a proxy on the same machine. Under Apache
>> 2.2, $r->remote_ip()
>> returned 127.0.0.1 and not the user's actual IP.  So, a
>> PerlPostReadRequestHandler extracted the user's
>> IP address from the X-Forwarded-For header and set it with $r->remote_ip(
>> $ip ).
>>
>> In Apache 2.4 (and mod_perl now) $c->remote_ip is split into
>> $r->useragent_ip and $c->client_ip:
>> http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>> But, $r->useragent_ip (wrongly) gives me 127.0.0.1. Perhaps this'll be
>> fixed
>> at some point (unless
>> I'm doing something wrong). So, for now, as above, the IP is extracted
>> from
>> X-Forwarded-For
>> and set with $r->useragent_ip( $ip ).
>
>
> Keep in mind you can't use r->useragent_ip until the request is created,
> e.g.
> the create request hook is not a good place to try this (we actually had to
> work around a crash related to this behavior in httpd's sources.) After the
> read_request phase, this information will be finalized (provided that the
> mod_remoteip config is correct).
>
> It seems some code was expecting to read the useragent_ip in a very early
> phase of connection handling, although the headers to populate it for the
> request had not even been read off the wire :) So now, all attempts to read
> this too-early will result in the c->client_ip values.
>
> Here's when the action happens;
> ap_hook_post_read_request(remoteip_modify_request, NULL, NULL,
> APR_HOOK_FIRST);

Yes, it seems PerlPostReadRequestHandler was too early. $r->useragent_ip()
gives the remote ip with the PerlTransHandler and later stages. Thanks!

Re: Where is the mod_perl development repo?

[William A Rowe Jr]

Explore the idea of wrapping your app as an fcgid endpoint. Httpd has two
options (mod_fcgid managing the pool, and mod_proxy_fcgi with your own
choice of independent pool management.)

This offers the best of both... Larger number of httpd endpoints and less
contention between fcgi processes. It is now the recommended approach to
PHP and other scripting endpoints.

On Feb 19, 2017 06:50, "Tom Browder"  wrote:

On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz 
wrote:

> > "Tom" == Tom Browder  writes:

...

>
Randall, I do know that, and I love Perl 6!  I also feel comfortable
writing CGI programs, so how can I use both most efficiently with my apache
web server.?

Best regards,

-Tom

P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016.
Thanks for all your contributions to the Perl community!

Absorb win32-apxs into httpd distro?

[William A Rowe Jr]

Randy wrote http://www.apache.org/dist/perl/win32-bin/ - but I'm wondering
who else here at httpd is interested in helping maintain and get this code
into our own distribution? I've shipped this for a decade for my commercial
customers, for every wrinkle and wart, I think many of our win32 users
would appreciate this.

I trust the perl pmc and Randy would be good with this adoption?

Cheers,

Bill

Re: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

Hi Jie,
If I temporarily disable B::Hooks::OP::Check, as shown below, then it
tells me it was included from Devel::Declare, which was in turn
(indireclty) included from Method::Signatures::Simple.
I am not the author of either Catalyst or ShinyCMS, so unfortunately I
don't know any more in-depth details off the top of my head.
Does that answer your question?
Thanks,~ Will
wbraswell@cloud-comp0-00:~$ pm_location.sh
B::Hooks::OP::Check/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
wbraswell@cloud-comp0-00:~$ mv
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/B/Hooks/OP/Check.pm.DISABLED
wbraswell@cloud-comp0-00:~/public_html/cloud-comp0-00.autoparallel.com-latest$
perl -e 'use ShinyCMS;'Can't locate B/Hooks/OP/Check.pm in @INC (you
may need to install the B::Hooks::OP::Check module) (@INC contains
) at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
line 18.BEGIN failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare.pm
line 18.Compilation failed in require at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
line 5.BEGIN failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/Context/Simple.pm
line 5.Compilation failed in require at /usr/share/perl/5.22/base.pm
line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/Devel/Declare/MethodInstaller/Simple.pm
line 3.Compilation failed in require at /usr/share/perl/5.22/base.pm
line 97. ...propagated at /usr/share/perl/5.22/base.pm line 106.BEGIN
failed--compilation aborted at
/home/wbraswell/perl5/lib/perl5/Method/Signatures/Simple.pm line
19.Compilation failed in require at blib/lib/ShinyCMS.pm line 21.BEGIN
failed--compilation aborted at blib/lib/ShinyCMS.pm line
21.Compilation failed in require at -e line 1.BEGIN
failed--compilation aborted at -e line 1.
On 11/22/2016 at 11:03 PM, "Jie Gao"  wrote:Hi William

Where excatly is B::Hooks::OP::Check required / its Check.xs called?
Regards,
Jie 

* William N. Braswell, Jr.  wrote:

> Date: Tue, 22 Nov 2016 06:04:36 -0600
> From: "William N. Braswell, Jr." 
> To: Jie Gao 
> CC: modperl@perl.apache.org
> Subject: RE: mod_perl Silent Failure, Very Mysterious
> 
> Hello Again Jie,
> I have run the modperl_testreport.pl script per your direction, and
> have attached the output file.
> Also, I have posted this as a mod_perl issue:
> 
> https://rt.cpan.org/Ticket/Display.html?id=118900
> I am attempting to run an already-bug-free Catalyst application
under
> mod_perl, which should work just fine but instead gives a segfault
in
> the Check.xs file.
> The name of the Catalyst application is ShinyCMS, it works just fine
> using the PSGI stand-alone testing web server as well as fastcgi,
and
> mod_perl is the only option which causes a segfault.  I must have
> mod_perl support for my specific use of ShinyCMS, so I really really
> need to fix this segfault and get Shiny working under mod_perl. 
Yes,
> Shiny is specifically designed to work with mod_perl, as are most
> Catalyst apps.  In fact, my simple ">" print statements in
ShinyCMS.pm
> show that Shiny is totally loading and returning control back to
> Apache (or mod_perl?) before the actual segfault occurs.
> My system info:
> $ apache2 -vServer version: Apache/2.4.18 (Ubuntu)Server built:  
> 2016-07-14T12:32:26
> $ perl -vThis is perl 5, version 22, subversion 1 (v5.22.1) built
for
> x86_64-linux-gnu-thread-multi(with 58 registered patches, see perl
-V
> for more detail)
> $ pm_version.pl mod_perl2$mod_perl2::VERSION = 2.09
> $ pm_version.pl B::Hooks::OP::Check$B::Hooks::OP::Check::VERSION =
> 0.19
> $ cat /etc/issueUbuntu 16.04.1 LTS
> I have spent the last week trying all of the following and more, but
> the segfault persists:
> 1.  manually-compiled perl v5.22.1 & mod_perl2 v2.09 w/out
> threads2.  mod_perl2 back to v2.053.  B::Hooks::OP::Check back
to
> v0.17 (maybe earlier)4.  move all possible 'use' statements to be
> called as early as possible in Shiny_dependencies.pm
> I also tried Apache v2.2 & mod_perl2 v2.08 & Perl v5.18.2 in
> Ubuntu v14.04, it did not segfault but instead it served up totally
> blank pages with 0 bytes of data.  I have not dug deeper because I
use
> Ubuntu v16.04 in production and I figure it is harder to debug w/out
> an actual segfault to start from.
> I have set up SSH access on a cloud server so you can see and debug
> the segfault directly, all 3 of the usernames below are set as
sudoers
> so please wield your root po

RE: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

directory.
(gdb) watch -l PL_check[17]Hardware watchpoint 3: -location
PL_check[17]
(gdb) continueContinuing.
Hardware watchpoint 3: -location PL_check[17]
Old value = (OP *(*)(PerlInterpreter *, OP *)) 0x73e4d9e0 New
value = (OP *(*)(PerlInterpreter *, OP *)) 0x7fffebabcb10
0x7fffebabcd0e in hook_op_check (type=type@entry=OP_RV2CV,
cb=cb@entry=0x7fffeb8b6d30 , user_data=user_data@entry=0x0) at
Check.xs:  PL_check[type] = check_cb;
(gdb) info threads  Id   Target Id Frame * 1Thread
0x77fe2780 (LWP 6196) "/usr/sbin/apach" 0x7fffebabcd0e in
hook_op_check (type=type@entry=OP_RV2CV, cb=cb@entry=0x7fffeb8b6d30 ,
user_data=user_data@entry=0x0)at Check.xs:66
(gdb) info sourceCurrent source file is Check.xsCompilation directory
is
/home/wbraswell/.cpanm/work/1479735542.24787/B-Hooks-OP-Check-0.19Located
in
/home/wbraswell/.cpanm/work/1479735542.24787/B-Hooks-OP-Check-0.19/Check.xsContains
106 lines.Source language is c.Producer is GNU C11 5.4.0 20160609
-mtune=generic -march=x86-64 -g -O2 -fwrapv -fno-strict-aliasing -fPIC
-fstack-protector-strong.Compiled with DWARF 2 debugging format.Does
not include preprocessor macro info.
(gdb) continueContinuing.>: top of ShinyCMS.pm>: in ShinyCMS.pm, about
to use Moose>: in ShinyCMS.pm, about to use Catalyst::Runtime>: in
ShinyCMS.pm, about to use Catalyst>: in ShinyCMS.pm, about to use
CatalystX::RoleApplicator>: in ShinyCMS.pm, about to use
Method::Signatures::Simple>: in ShinyCMS.pm, about to call config()>:
in ShinyCMS.pm, have __PACKAGE__ = ShinyCMS>: in ShinyCMS.pm, about to
call setup()...>: in ShinyCMS.pm, returned from setup()>: in
ShinyCMS.pm, about to return 1
...
Program received signal SIGSEGV, Segmentation fault.0x7fffebabcb10
in ?? ()(gdb) bt#0  0x7fffebabcb10 in ?? ()#1  0x73e5302b
in Perl_newUNOP (my_perl=my_perl@entry=0x59dd8ed0,
type=type@entry=17, flags=, flags@entry=8192, first=0x5824eb98) at
op.c:4811#2  0x73e54a1d in Perl_newCVREF
(my_perl=my_perl@entry=0x59dd8ed0, flags=flags@entry=8192, o=) at
op.c:9367...#44 0x5558709f in main ()
(gdb) print PL_check[17]$1 = (Perl_check_t) 0x7fffebabcb10
(gdb) quit
[[[ END GDB SESSION ]]]
I have attached the unabbreviated gdb session and the system info in
text files, for your reference.
I am anxious (near desperate) to get this bug fixed so that I can move
forward with my work.  I will eagerly assist in any way I can, please
just let me know what I should do and I will do it!
Thanks so much for your help.
Perling,~ Will

On 11/16/2016 at 3:17 AM, "Jie Gao"  wrote: For the completeness
of issue reporting, please run the following script and post the
output:
 #!/usr/bin/perl
 use strict;
 use warnings FATAL => 'all';
 use ModPerl::TestReport;
 ModPerl::TestReport->new(@ARGV)->run;
 Jie
-
 From: William N. Braswell, Jr. [william.brasw...@autoparallel.com]
 Sent: Tuesday, November 15, 2016 8:01 PM
 To: Jie Gao
 Cc: modperl@perl.apache.org
 Subject: Re: mod_perl Silent Failure, Very Mysterious
Hello Jie & Friends, 
  I got the core dump out of gdb and also some hopefully-helpful
output. 
  Here is the output from gdb (not the core dump which is binary of
course): 
  http://hastebin.com/okaxacuriq.scala
 Then again maybe we have a problem because I'm missing debugging
symbols inside /usr/sbin/apache2?
 _Program received signal SIGSEGV, Segmentation fault.   
0x7fffeed67a00 in ?? ()_
 Note the _??_ part in the output above... 
  Where do I go from here? 
  Thanks, ~ Will 
 On 11/15/2016 at 12:14 AM, "William N. Braswell, Jr."  wrote:   Hi
Jie, 
  I have captured the output of `strace -f /usr/sbin/apache2 -e trace8
-k start`: 
  http://hastebin.com/unupocozop.pl 
  Looks like it is dying with a segfault, but I'm not sure what is
causing this??? 
  Thanks so much for your help!!!  :-) 
  ~ Will 
  [[[ BEGIN PASTE SNIPPET ]]] 
   [pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1
ENOENT (No such file or directory) [pid  6550]
stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory) [pid  6550] stat("/etc/perl/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory) [pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) =
-1 ENOENT (No such file or directory) [pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) =
-1 ENOENT (No such file or directory) [pid  6550]
stat(&quo

Re: mod_perl Silent Failure, Very Mysterious

[William N. Braswell, Jr.]

Hello Jie & Friends,
I got the core dump out of gdb and also some hopefully-helpful output.
Here is the output from gdb (not the core dump which is binary of
course):
http://hastebin.com/okaxacuriq.scala

Then again maybe we have a problem because I'm missing debugging
symbols inside /usr/sbin/apache2?

_Program received signal SIGSEGV, Segmentation fault.   
0x7fffeed67a00 in ?? ()_

Note the _??_ part in the output above...
Where do I go from here?
Thanks,~ Will

On 11/15/2016 at 12:14 AM, "William N. Braswell, Jr."  wrote:Hi Jie,
I have captured the output of `strace -f /usr/sbin/apache2 -e trace8
-k start`:
http://hastebin.com/unupocozop.pl
Looks like it is dying with a segfault, but I'm not sure what is
causing this???
Thanks so much for your help!!!  :-)
~ Will

[[[ BEGIN PASTE SNIPPET ]]]
[pid  6550] stat("blib/lib/DynaLoader.pmc", 0x7ffdda87f280) = -1
ENOENT (No such file or directory)[pid  6550]
stat("blib/lib/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550] stat("/etc/perl/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/etc/perl/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No such
file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/lib/x86_64-linux-gnu/perl/5.22.1/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pmc", 0x7ffdda87f280) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/local/share/perl/5.22.1/DynaLoader.pm", 0x7ffdda87f1b0) =
-1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl5/5.22/DynaLoader.pm",
0x7ffdda87f1b0) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pmc", 0x7ffdda87f280) = -1 ENOENT
(No such file or directory)[pid  6550]
stat("/usr/share/perl5/DynaLoader.pm", 0x7ffdda87f1b0) = -1 ENOENT (No
such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pmc",
0x7ffdda87f280) = -1 ENOENT (No such file or directory)[pid  6550]
stat("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm",
{st_mode=S_IFREG|0644, st_size=10748, ...}) = 0[pid  6550]
open("/usr/lib/x86_64-linux-gnu/perl/5.22/DynaLoader.pm", O_RDONLY) =
5[pid  6550] ioctl(5, TCGETS, 0x7ffdda87ef50) = -1 ENOTTY
(Inappropriate ioctl for device)[pid  6550] lseek(5, 0, SEEK_CUR) 
 = 0[pid  6550] read(5, "# Generated from DynaLoader_pm.P"..., 8192) =
8192[pid  6550] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7f491064fa00} ---[pid  6550] chdir("/etc/apache2")   =
0[pid  6550] rt_sigaction(SIGSEGV, {SIG_DFL, [],
SA_RESTORER|SA_INTERRUPT, 0x7f4918dea3d0}, {SIG_DFL, [],
SA_RESTORER|SA_RESETHAND, 0x7f4918dea3d0}, 8) = 0[pid  6550]
kill(6550, SIGSEGV) = 0[pid  6550] rt_sigreturn({mask=[]})
= 139951873083648[pid  6550] --- SIGSEGV {si_signo=SIGSEGV,
si_code=SI_USER, si_pid=6550, si_uid=0} ---[pid  6549] +++ exited with
0 ++ killed by SIGSEGV (core dumped) +++
[[[ END PASTE SNIPPET ]]]
On 11/14/2016 at 11:54 PM, "Jie Gao"  wrote:Add the "-f" flag to
strace and see what errors you get.
Regards,

Jie 

* William N. Braswell, Jr.  wrote:

> Date: Mon, 14 Nov 2016 23:27:53 -0600
> From: "William N. Braswell, Jr." 
> To: modperl@perl.apache.org
> Subject: mod_perl Silent Failure, Very Mysterious
> 
> Hello everyone, I'm trying to enable a web app (Catalyst ShinyCMS)
to
> run under mod_perl, it is definitely supposed to work but it fails
> without any errors, and I've been trying for several days to get it
> working.
> My system info:
> * Perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-linux-gnu-thread-multi
> * libapache2-mod-perl2 v2.0.9-4ubuntu1
> * Apache/2.4.18 (Ubuntu)
> * $Apache::Test::VERSION = 1.39
> * $Catalyst::VERSION = 5.90112
> * $ShinyCMS::VERSION = 0.007
> I know the app already functions properly when running via the
> stand-alone test server script (PSGI) or fastcgi, and I am able to
run
> a trivial Catalyst test application successfully under mod_perl, so
> this issue seems to have something to do with the interaction
between
> the ShinyCMS app and mod_perl.
> I have added print debug statements in my app, so when I call my app
> from within the Apache site conf file then I can see the debug
> statements prove that it is successfully going all the way through
my
> app, and it even returns control to the embedded  code w/in the
Apache
> site conf file, bu

Re: Bug - Strange issue with mod_perl 2.0.10 / Apache 2.4 corrupting nfreeze data

[William A Rowe Jr]

On Sun, Aug 7, 2016 at 8:37 AM, Alex Masidlover 
wrote:

> On Sun, 2016-04-03 at 17:03 +0200, Vincent Veyron wrote:
> > On Sun, 03 Apr 2016 14:11:23 +0100
> > Alex Masidlover  wrote:
> >
> > > This has all worked perfectly up until I upgraded to Apache 2.4 /
> > > mod_perl 2.0.10 -
> > After upgrading to Apache 2.4 and mod_perl 2.0.9, I had to make those
> > two changes to my application :
> >
> > In a PerlOutputFilterHandler, change '$content .= $buffer' to
> > '$content .= decode_utf8($buffer)'
> >
> > And in response handlers, change '$args{$_} = $req->param($_)' to
> > '$args{$_} = decode_utf8($req->param($_))'
> >
> > Not sure it applies to your case, but something changed in Apache 2.4
> > concerning UTF-8 data.
> >
> > If I understood correctly, anything that goes through APR::Table is
> > considered UTF-8, however the SvUTF8 flag is not set, so you get
> > double encoding when processing your data.
>

Just to be clear, everything in APR::Table is expected to be ASCII
(or EBCDIC, on those oddball architectures)... and "opaque text",
e.g. characters 128-255 on ASCII architectures is permitted but
not defined.

It's easy to verify that they qualify as UTF-8, because the coding is very
predictable.  E.g. 0xFE or 0xFF are not characters, and others are valid
only when in the correct sequence, c.f. the validation logic in;

  http://svn.apache.org/repos/asf/apr/apr/trunk/misc/win32/utf8.c


> What a browser sends is not guaranteed, it may be sending ISO-8859-1,
or UTF8 (or even problematic ISO-2022-JP where the ASCII char ' ' or '\'
may occur as a continuation character causing parsing issues. Modern
browsers appear to all be defaulting to UTF-8 finally, but you may have
many legacy browsers out there.

In your decode_utf8 logic, ensure that your app checks for failure!  And
where the output fails, try treating it in a code page such as 8859-1.

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William Ward]

Thanks for the heads up ... will definitely put that on the roadmap. For 
now I will stick to 2.2 to reduce the number of things that might go 
wrong, but once we get stable on this version I'll look into 2.4


Bill


On 7/22/2016 12:27 PM, John D Groenveld wrote:

In message 

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William A Rowe Jr]

On Jul 21, 2016 8:24 PM, "William Ward" <william.w...@oracle.com> wrote:
>
> OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with
LTS status by the Perl gods. Hopefully a new mod_perl will come out that
includes this fix.

Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2
as well. You would do well to build your httpd 2.4 / perl 5.24 / mod
perl.next that should be tagged soon as your next stack.

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William Ward]

Sorry, with all the things we're upgrading I don't want to add the 
variable of experimental code into the mix. I'll just run 5.20.3 for now.


Bill


On 7/22/2016 12:12 AM, Steve Hay wrote:

Yes, I intend to make a new mod_perl release with the fix very soon
after two maint perl releases (5.22.3 / 5.24.1) are done. Sorry this
fix has languished so long.

In the meantime, if you're able to grab the latest SVN source and try
it then that would be a great help: It should be good to go, but more
testing is mostly what it needs.


On 22 July 2016 at 02:24, William Ward <william.w...@oracle.com> wrote:

OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS
status by the Perl gods. Hopefully a new mod_perl will come out that
includes this fix.

Bill.



On 7/21/2016 6:10 PM, Adam Prime wrote:

there are changes in SVN to support perls >= 5.22, but the work hasn't
been released and may not be complete yet.  This is the bug:

https://rt.cpan.org/Public/Bug/Display.html?id=101962

If you can downgrade your perl to 5.20 then you should be able to get
things running.

Adam


On 07/21/2016 05:16 PM, William Ward wrote:

-8<-- Start Bug Report 8<--
1. Problem Description:

Until recently we have been using Perl 5.8.8, Apache 2.2.29, and
mod_perl 2.0.8. Due to migration to a new platform, it is necessary to
rebuild our tech stack, so I am taking this opportunity to upgrade
(Perl 5.8.8 doesn't want to build on the new platform anyway).

Everything compiles fine, and Apache and Perl have no issues but
mod_perl has failures running "make test":

Test Summary Report
---
t/api/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
Parse errors: Bad plan.  You planned 24 tests but ran 12.
t/apr-ext/uri.t   (Wstat: 65280 Tests: 12 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/apr/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/directive/perlloadmodule3.t (Wstat: 0 Tests: 3 Failed: 3)
Failed tests:  1-3
t/filter/both_str_native_remove.t (Wstat: 0 Tests: 8 Failed: 4)
Failed tests:  1, 6-8
t/modperl/print.t (Wstat: 0 Tests: 5 Failed: 0)
Parse errors: Bad plan.  You planned 6 tests but ran 5.
t/modperl/printf.t(Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: No plan found in TAP output
Files=245, Tests=2223, 136 wallclock secs ( 1.16 usr 2.63 sys + 80.27
cusr 35.91 csys = 119.97 CPU)
Result: FAIL
Failed 7/245 test programs. 7/2223 subtests failed.

I re-ran the tests mentioned above using -verbose mode, and the
results are below.

% t/TEST -verbose api/uri apr-ext/uri apr/uri
directive/perlloadmodule3 filter/both_str_native_remove modperl/print
modperl/printf
[warning] setting ulimit to allow core files
ulimit -c unlimited; /arudev/tech-stack/16.09.16.06/linux/bin/perl

/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/TEST
-verbose 'api/uri' 'apr-ext/uri' 'apr/uri' 'directive/perlloadmodule3'
'filter/both_str_native_remove' 'modperl/print' 'modperl/printf'
/arudev/tech-stack/16.09.16.06/linux/bin/httpd  -d

/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t
-f

/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/conf/httpd.conf
-D APACHE2
using Apache/2.2.31 (prefork MPM)

waiting 120 seconds for server to start: .[Thu Jul 21 14:01:34 2016]
[info] 6 Apache2:: modules loaded
[Thu Jul 21 14:01:34 2016] [info] 0 APR:: modules loaded
[Thu Jul 21 14:01:34 2016] [info] base server + 29 vhosts ready to run
tests
..
waiting 120 seconds for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
server localhost.localdomain:8530 listening (perlsections)
server localhost.localdomain:8531 listening (inherit)
server localhost.localdomain:8532 listening (filter_out_apache)
server localhost.localdomain:8533 listening (TestVhost::log)
server localhost.localdomain:8534 listening (TestVhost::config)
server localhost.localdomain:8535 listening (TestModperl::setupenv)
server localhost.localdomain:8536 listening (TestModperl::perl_options2)
server localhost.localdomain:8537 listening (TestModperl::perl_options)
server localhost.localdomain:8538 listening (TestModperl::merge)
server localhost.localdomain:8539 listening
(TestDirective::perlcleanuphandler)
server localhost.localdomain:8540 listening (TestModules::proxy)
server localhost.localdomain:8541 listening (TestUser::rewrite)
server localhost.localdomain:8542 listening (TestProtocol::echo_bbs)
server localhost.localdomain:8543 listening (TestProtocol::echo_timeout)
server localhost.localdomain:8544 listening (TestProtocol::echo_block)
server localhost.localdomain:8545 listening (TestProtocol::pseudo_http)
ser

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William Ward]

I thought I saw somewhere the term LTS used with respect to Perl 5.24 
but can't find it now... however they do push pretty hard to run the 
latest version:


 * On https://www.perl.org/get.html it says, "We recommend that you
   always run the latest stable version, currently 5.24.0. If you're
   running a version older than 5.8.3, you may find that the latest
   version of CPAN modules will not work."
 * On http://www.cpan.org/src/README.html it says "End of life" for all
   versions earlier than 5.22.2

If mod_perl doesn't work on any version except those marked "End of 
life" in CPAN, I think that's a problem.

Bill

On 7/22/2016 1:47 AM, Dominic Hargreaves wrote:

On Thu, Jul 21, 2016 at 06:24:05PM -0700, William Ward wrote:

OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS
status by the Perl gods. Hopefully a new mod_perl will come out that
includes this fix.

Where do you find a reference to LTS support for perl 5.24.0? As far
as I know the support policy is unchanged and uniform for each stable
release:

http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT

Cheers,
Dominic.

Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William Ward]

OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with 
LTS status by the Perl gods. Hopefully a new mod_perl will come out that 
includes this fix.


Bill.


On 7/21/2016 6:10 PM, Adam Prime wrote:

there are changes in SVN to support perls >= 5.22, but the work hasn't
been released and may not be complete yet.  This is the bug:

https://rt.cpan.org/Public/Bug/Display.html?id=101962

If you can downgrade your perl to 5.20 then you should be able to get
things running.

Adam


On 07/21/2016 05:16 PM, William Ward wrote:

-8<-- Start Bug Report 8<--
1. Problem Description:

Until recently we have been using Perl 5.8.8, Apache 2.2.29, and
mod_perl 2.0.8. Due to migration to a new platform, it is necessary to
rebuild our tech stack, so I am taking this opportunity to upgrade
(Perl 5.8.8 doesn't want to build on the new platform anyway).

Everything compiles fine, and Apache and Perl have no issues but
mod_perl has failures running "make test":

Test Summary Report
---
t/api/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
   Parse errors: Bad plan.  You planned 24 tests but ran 12.
t/apr-ext/uri.t   (Wstat: 65280 Tests: 12 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/apr/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
   Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/directive/perlloadmodule3.t (Wstat: 0 Tests: 3 Failed: 3)
   Failed tests:  1-3
t/filter/both_str_native_remove.t (Wstat: 0 Tests: 8 Failed: 4)
   Failed tests:  1, 6-8
t/modperl/print.t (Wstat: 0 Tests: 5 Failed: 0)
   Parse errors: Bad plan.  You planned 6 tests but ran 5.
t/modperl/printf.t(Wstat: 65280 Tests: 0 Failed: 0)
   Non-zero exit status: 255
   Parse errors: No plan found in TAP output
Files=245, Tests=2223, 136 wallclock secs ( 1.16 usr 2.63 sys + 80.27
cusr 35.91 csys = 119.97 CPU)
Result: FAIL
Failed 7/245 test programs. 7/2223 subtests failed.

I re-ran the tests mentioned above using -verbose mode, and the
results are below.

% t/TEST -verbose api/uri apr-ext/uri apr/uri
directive/perlloadmodule3 filter/both_str_native_remove modperl/print
modperl/printf
[warning] setting ulimit to allow core files
ulimit -c unlimited; /arudev/tech-stack/16.09.16.06/linux/bin/perl
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/TEST
-verbose 'api/uri' 'apr-ext/uri' 'apr/uri' 'directive/perlloadmodule3'
'filter/both_str_native_remove' 'modperl/print' 'modperl/printf'
/arudev/tech-stack/16.09.16.06/linux/bin/httpd  -d
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t
-f
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/conf/httpd.conf
-D APACHE2
using Apache/2.2.31 (prefork MPM)

waiting 120 seconds for server to start: .[Thu Jul 21 14:01:34 2016]
[info] 6 Apache2:: modules loaded
[Thu Jul 21 14:01:34 2016] [info] 0 APR:: modules loaded
[Thu Jul 21 14:01:34 2016] [info] base server + 29 vhosts ready to run
tests
..
waiting 120 seconds for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
server localhost.localdomain:8530 listening (perlsections)
server localhost.localdomain:8531 listening (inherit)
server localhost.localdomain:8532 listening (filter_out_apache)
server localhost.localdomain:8533 listening (TestVhost::log)
server localhost.localdomain:8534 listening (TestVhost::config)
server localhost.localdomain:8535 listening (TestModperl::setupenv)
server localhost.localdomain:8536 listening (TestModperl::perl_options2)
server localhost.localdomain:8537 listening (TestModperl::perl_options)
server localhost.localdomain:8538 listening (TestModperl::merge)
server localhost.localdomain:8539 listening
(TestDirective::perlcleanuphandler)
server localhost.localdomain:8540 listening (TestModules::proxy)
server localhost.localdomain:8541 listening (TestUser::rewrite)
server localhost.localdomain:8542 listening (TestProtocol::echo_bbs)
server localhost.localdomain:8543 listening (TestProtocol::echo_timeout)
server localhost.localdomain:8544 listening (TestProtocol::echo_block)
server localhost.localdomain:8545 listening (TestProtocol::pseudo_http)
server localhost.localdomain:8546 listening (TestProtocol::echo_filter)
server localhost.localdomain:8547 listening (TestProtocol::echo_bbs2)
server localhost.localdomain:8548 listening (TestProtocol::echo_nonblock)
server localhost.localdomain:8549 listening (TestPreConnection::note)
server localhost.localdomain:8550 listening (TestHooks::init)
server localhost.localdomain:8551 listening (TestHooks::startup)
server localhost.localdomain:8552 listening (TestHooks::hookrun)
server localhost.localdomain:8553 listening
(TestHooks::stacked_handlers2)
server localhost.localdomain:8554 listening (TestHooks::trans)
server lo

[mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)

[William Ward]

-8<-- Start Bug Report 8<--
1. Problem Description:

Until recently we have been using Perl 5.8.8, Apache 2.2.29, and 
mod_perl 2.0.8. Due to migration to a new platform, it is necessary to 
rebuild our tech stack, so I am taking this opportunity to upgrade (Perl 
5.8.8 doesn't want to build on the new platform anyway).


Everything compiles fine, and Apache and Perl have no issues but 
mod_perl has failures running "make test":


Test Summary Report
---
t/api/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
  Parse errors: Bad plan.  You planned 24 tests but ran 12.
t/apr-ext/uri.t   (Wstat: 65280 Tests: 12 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/apr/uri.t   (Wstat: 0 Tests: 12 Failed: 0)
  Parse errors: Bad plan.  You planned 36 tests but ran 12.
t/directive/perlloadmodule3.t (Wstat: 0 Tests: 3 Failed: 3)
  Failed tests:  1-3
t/filter/both_str_native_remove.t (Wstat: 0 Tests: 8 Failed: 4)
  Failed tests:  1, 6-8
t/modperl/print.t (Wstat: 0 Tests: 5 Failed: 0)
  Parse errors: Bad plan.  You planned 6 tests but ran 5.
t/modperl/printf.t(Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=245, Tests=2223, 136 wallclock secs ( 1.16 usr 2.63 sys + 80.27 
cusr 35.91 csys = 119.97 CPU)

Result: FAIL
Failed 7/245 test programs. 7/2223 subtests failed.

I re-ran the tests mentioned above using -verbose mode, and the results 
are below.


% t/TEST -verbose api/uri apr-ext/uri apr/uri directive/perlloadmodule3 
filter/both_str_native_remove modperl/print modperl/printf

[warning] setting ulimit to allow core files
ulimit -c unlimited; /arudev/tech-stack/16.09.16.06/linux/bin/perl 
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/TEST 
-verbose 'api/uri' 'apr-ext/uri' 'apr/uri' 'directive/perlloadmodule3' 
'filter/both_str_native_remove' 'modperl/print' 'modperl/printf'
/arudev/tech-stack/16.09.16.06/linux/bin/httpd  -d 
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t 
-f 
/scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/conf/httpd.conf 
-D APACHE2

using Apache/2.2.31 (prefork MPM)

waiting 120 seconds for server to start: .[Thu Jul 21 14:01:34 2016] 
[info] 6 Apache2:: modules loaded

[Thu Jul 21 14:01:34 2016] [info] 0 APR:: modules loaded
[Thu Jul 21 14:01:34 2016] [info] base server + 29 vhosts ready to run tests
..
waiting 120 seconds for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
server localhost.localdomain:8530 listening (perlsections)
server localhost.localdomain:8531 listening (inherit)
server localhost.localdomain:8532 listening (filter_out_apache)
server localhost.localdomain:8533 listening (TestVhost::log)
server localhost.localdomain:8534 listening (TestVhost::config)
server localhost.localdomain:8535 listening (TestModperl::setupenv)
server localhost.localdomain:8536 listening (TestModperl::perl_options2)
server localhost.localdomain:8537 listening (TestModperl::perl_options)
server localhost.localdomain:8538 listening (TestModperl::merge)
server localhost.localdomain:8539 listening 
(TestDirective::perlcleanuphandler)

server localhost.localdomain:8540 listening (TestModules::proxy)
server localhost.localdomain:8541 listening (TestUser::rewrite)
server localhost.localdomain:8542 listening (TestProtocol::echo_bbs)
server localhost.localdomain:8543 listening (TestProtocol::echo_timeout)
server localhost.localdomain:8544 listening (TestProtocol::echo_block)
server localhost.localdomain:8545 listening (TestProtocol::pseudo_http)
server localhost.localdomain:8546 listening (TestProtocol::echo_filter)
server localhost.localdomain:8547 listening (TestProtocol::echo_bbs2)
server localhost.localdomain:8548 listening (TestProtocol::echo_nonblock)
server localhost.localdomain:8549 listening (TestPreConnection::note)
server localhost.localdomain:8550 listening (TestHooks::init)
server localhost.localdomain:8551 listening (TestHooks::startup)
server localhost.localdomain:8552 listening (TestHooks::hookrun)
server localhost.localdomain:8553 listening (TestHooks::stacked_handlers2)
server localhost.localdomain:8554 listening (TestHooks::trans)
server localhost.localdomain:8555 listening (TestFilter::both_str_con_add)
server localhost.localdomain:8556 listening (TestFilter::in_bbs_msg)
server localhost.localdomain:8557 listening 
(TestFilter::in_bbs_inject_header)

server localhost.localdomain:8558 listening (TestFilter::in_str_msg)
server localhost.localdomain:8559 listening (TestDirective::perlrequire)
server localhost.localdomain:8560 listening (TestDirective::perlmodule)
server localhost.localdomain:8561 listening (TestDirective::perlloadmodule3)
server localhost.localdomain:8562 listening 

Re: ApacheCon: Getting the word out internally

[William A Rowe Jr]

It isn't undergoing significant changes, but 2.0.9 fixed several bugs and
brought it up-to-date with then-current perl releases a year ago June, and
I understand there is some activity to have it build well with 5.24.

On Jul 18, 2016 10:17 PM,  wrote:

> Hi,
>
> Is Apache modperl still in active development?
>
> thanks.
>
> On 2016/7/19 3:54, Melissa Warnkin wrote:
>
>> ApacheCon: Getting the word out internally
>>
>> Dear Apache Enthusiast,
>>
>> As you are no doubt already aware, we will be holding ApacheCon in
>> Seville, Spain, the week of November 14th, 2016. The call for papers
>> (CFP) for this event is now open, and will remain open until
>> September 9th.
>>
>> The event is divided into two parts, each with its own CFP. The first
>> part of the event, called Apache Big Data, focuses on Big Data
>> projects and related technologies.
>>
>> Website: http://events.linuxfoundation.org/events/apache-big-data-europe
>> CFP:
>>
>> http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp
>>
>> The second part, called ApacheCon Europe, focuses on the Apache
>> Software Foundation as a whole, covering all projects, community
>> issues, governance, and so on.
>>
>> Website: http://events.linuxfoundation.org/events/apachecon-europe
>> CFP:
>> http://events.linuxfoundation.org/events/apachecon-europe/program/cfp
>>
>> ApacheCon is the official conference of the Apache Software
>> Foundation, and is the best place to meet members of your project and
>> other ASF projects, and strengthen your project's community.
>>
>> If your organization is interested in sponsoring ApacheCon, contact Rich
>> Bowen
>> at e...@apache.org   ApacheCon is a great place to
>> find the brightest
>> developers in the world, and experts on a huge range of technologies.
>>
>> I hope to see you in Seville!
>> ==
>> **//___^
>>
>> Melissa
>> on behalf of the ApacheCon Team**//___^
>>
>

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On May 29, 2016 01:02, "Jie Gao" <j@sydney.edu.au> wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty in an attmpt to get the ball
> rolling. Any help on how to get a handle on the "ip comparisons"
> recommended by W. Rowe Jr would be much appreciated.
>
> Hi Jie,
>
> At the moment, I'm still on the fence of whether this is a supportable use
> case (in the faux-handler for the modperl alt protocol example.)
>
> If it is not, the fix is to drop the test from modperl.
>

Alternately, the test could be fixed, but that is non-trivial...

A non-request oriented alt protocol simply never examines the req_rec,
and must not use request oriented modules like auth.  That should be
pretty obvious.

To create a pseudo -request- handler, you would have your connection
hook handler populate the appropriate fields and insert the appropriate
protocol-specific input and output filters below the request/body filters
and run the request through the rest of the phases, performing the
auth validation at the appropriate phase of the request (post_read
would be one obvious choice.)

Otherwise, the fix is also straightforward, I can provide hints, but you
> can cause the fault by changing the domain name in the test case config
> from example 'hostname' to example 'ip addr'.  The offending code is in the
> backtrace.  Both ip and host lookups would test if the useragent_addr is
> null, and use the corresponding lookups from the conn_rec.
>
> I sort of expect the modperl test to continue to be broken because the
> req_rec simply has not been fully initialized... it is not until the entire
> read_req hook phase is complete that all these req_rec field members have
> meaningful values.
>
> But if enough folks agree we can fix the lookup to refer to the conn_rec
> values until useragent_addr is initialized.
>

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On May 29, 2016 01:02, "Jie Gao"  wrote:
>
> Hi All
>
> I wonder if anybody is looking at this issue. At the moment, the build
cores even at the end of generating a Makefile.
>
> If not, I would like to get my hands dirty in an attmpt to get the ball
rolling. Any help on how to get a handle on the "ip comparisons"
recommended by W. Rowe Jr would be much appreciated.

Hi Jie,

At the moment, I'm still on the fence of whether this is a supportable use
case (in the faux-handler for the modperl alt protocol example.)

If it is not, the fix is to drop the test from modperl.

Otherwise, the fix is also straightforward, I can provide hints, but you
can cause the fault by changing the domain name in the test case config
from example 'hostname' to example 'ip addr'.  The offending code is in the
backtrace.  Both ip and host lookups would test if the useragent_addr is
null, and use the corresponding lookups from the conn_rec.

I sort of expect the modperl test to continue to be broken because the
req_rec simply has not been fully initialized... it is not until the entire
read_req hook phase is complete that all these req_rec field members have
meaningful values.

But if enough folks agree we can fix the lookup to refer to the conn_rec
values until useragent_addr is initialized.

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

Re-sending to include the correct perl.a.o dev list.

On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
>
> First, the handler is registered using
>
>   PerlProcessConnectionHandler TestProtocol::pseudo_http
>
> so its activities are outside of the request handling phase.
>
> Note that this logic has been broken, for a long time;
>
>2.4.1>
>   
>   Order Deny,Allow
>   Allow from @servername@
>   
>   
>
> Where @servername@ is a hostname, this module defect was
> identified in version 2.4.20 when we began using the per-req
> hostname in comparison (based on r->useragent_addr, which
> is obviously is null during part of the read_request phase).
>
> But this module using mod_access_compat during the connection
> phase has been broken for much longer, since Allow from {ip-addr}
> would already have failed since 2.4.1 was released, due to the
> same null r->useragent_addr.
>
> Effectively, mod_access_compat.c never supported per-connection
> IP addresses since it was added.  The fact that it supported
> per-connection hostname comparison was a quirk, and that the
> pseudo_http tests only looked at hostname and not ip comparisons
> was an oversight.
>
> But the module will fail in other manners if attempting to use
> http request_rec processing since that record is never fleshed
> out with the proper read/post_read request hook phases.
>
> My thought is to simply decouple access_compat from this
> module test... opinions?
>
> See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
>
>
> On Thu, Apr 14, 2016 at 11:55 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
>> We can be more vigilant about unexpectedly null values, however...
>>
>> how are you running request processing in the connection callback
>> of mod_perl?  That makes no sense, and probably signals a deeper
>> logic error.
>>
>> The access checker is configured per-dir, so until the request rec
>> is completely initialized during read_request, this doesn't make
>> much sense to me (full backtrace .. including frames #6-#10, for
>> those who are curious...)
>>
>> Either the callback list registered for modperl_callback_connection,
>> or the Perl_runops_standard, or the Perl_pp_entersub invoking the
>> run_access_checker hook seem the most suspect here.
>>
>> #0  apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, 
>> flags=flags@entry=0)
>> at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663
>> #1  0x55feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, 
>> type=type@entry=3,
>> str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990
>> #2  0x7fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, 
>> method=method@entry=0, a=,
>> a=) at mod_access_compat.c:279
>> #3  0x7fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at 
>> mod_access_compat.c:332
>> #4  0x55feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) 
>> at request.c:87
>> #5  0x7fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker 
>> (my_perl=0x55feb2964a20, cv=)
>> at HookRun.c:235
>> #6  0x7fd44f5f7e6a in Perl_pp_entersub () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #7  0x7fd44f5f0ca6 in Perl_runops_standard () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #8  0x7fd44f575f06 in Perl_call_sv () from 
>> /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #9  0x7fd44f91ec28 in modperl_callback 
>> (my_perl=my_perl@entry=0x55feb2964a20, handler=0x7fd4461f2750,
>> p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, 
>> args=0x55feb3beebd0)
>> at modperl_callback.c:100
>> #10 0x7fd44f91f576 in modperl_callback_run_handlers (idx=0, 
>> type=type@entry=1, r=r@entry=0x0,
>> c=, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, 
>> ptemp=0x0, run_mode=MP_HOOK_RUN_FIRST)
>> at modperl_callback.c:236
>> #11 0x7fd44f91fd4f in modperl_callback_connection (idx=, 
>> c=,
>> run_mode=) at modperl_callback.c:359
>> #12 0x55feaf10cdf0 in ap_run_process_connection 
>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>> #13 0x55feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, 
>> csd=csd@entry=0x7fd4461f20a0)
>> at connection.c:226
>> #14 0x7fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, 
>> my_thread_num=1, my_ch

Re: Minor issue with AuthenNTLM

[William A. Rowe Jr.]

On 3/30/2012 1:56 AM, Dami Laurent (PJ) wrote:
 -Message d'origine-
 De : André Warnier [mailto:a...@ice-sa.com]

 I was considering forking the module and fixing bugs like these, but I
 am not quite sure how much sense that makes given the fact that NTLM is
 deprecated technology.

 Huh ? Who said that ?  To my knowledge, 99% of large corporations use NTLM
 (Windows Domain
 Authentication) as their basic AAA mechanism.

Well, NTLM was DoA.  It is isn't HTTP compatible (0.9, 1.0 or 1.1).  HTTP is 
stateless, MS
NTLM presumes a stateful connection.

 For the future, the way to go is Kerberos; this is what Microsoft is pushing 
 in replacement for NTLM. 

Bingo.

Re: highscalability.com report

[William A. Rowe Jr.]

On 4/3/2012 9:50 PM, Jim Schueler wrote:
 Hope this doesn't get trapped by too many spam filters.
 
 Sad news.  Just saw a blog
 
   http://www.highscalability.com/
 
 that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
 reported 10%
 improvement in speed, but I haven't noticed :).
 
 After a couple months of total immersion, I have less inclination towards
 PHP than ever.  Fight's not out of me yet.

If one is comparing an every-connection mod_perl enabled environment
to a specific-content, fastcgi-proxied php buildout, there's no contest.

When was the last time you built perl with no threading support?  It's
certainly a 5%-15% win.

Re: highscalability.com report

[William A. Rowe Jr.]

On 4/4/2012 1:41 PM, Fred Moyer wrote:
 On Wed, Apr 4, 2012 at 6:37 AM, demerphq demer...@gmail.com wrote:
 On 4 April 2012 09:31, William A. Rowe Jr. wr...@rowe-clan.net wrote:

 When was the last time you built perl with no threading support?  It's
 certainly a 5%-15% win.

 Not certainly. We did that and saw almost no difference.
 
 I've done two perlbench sets of comparisons with threaded/non-threaded
 across a couple different versions of perl. I don't have the results
 posted on the web anymore, but non-threaded was up to 20% faster for
 some operations.
 
 As far as real world differences go, I don't think you are likely to
 see differences with mod_perl in production environments with threaded
 vs non-threaded.  That 20% increase probably only affects 1% of your
 application.

Right.  The missing detail/point was that a well-tuned pool of single
threaded PHP, or Perl, or assembly coded worker processes running under
fcgid is going to outperform the in-process model, given finite cpu and
memory resources.

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Tue, 06/28/11 at 16:50:
 
  Some in this thread :
 
  http://www.gossamer-threads.com/lists/modperl/modperl/103167
 
 The problem here didn't appear to be 5.14 compatibility, more an issue
 of an inexperienced user trying to setup the latest version of
 httpd/perl/mod_perl.  No specific 5.14 incompatibilities were
 identified.

I am a bit surprised by your summary of my problem.  I have been a
user of FreeBSD since 1996 and have found the FreeBSD ports system
to be an excellent resource and advantage to the UNIX world.

The way I insure my systems are relatively free of security risks is
to keep my operating system up-to-date and my applications rebuilt
when security issues are disseminated.

 It is always a good idea to use the tested and packaged versions of
 mod_perl/httpd that come with your operating system if you are looking
 to deploy a production application and don't have much experience with
 compiling from source.

Note that I most certainly am using/building the apache2 and mod_perl2 
that come with my operating system.  In fact, I would be had pressed
to consider doing otherwise.

While I am not by any measure an expert on mod_perl (1 or 2), a recent
well respected application required me to build apache2 and mod_perl2
in order to run that Perl application.  And when I say build here, I
mean build from source using the FreeBSD ports system.  Prior to my
June 9th upgrade of both my operating system and all my ports (all the
user-land applications), I had been running apache2 (2.1.7) along with
mod_perl2 (2.0.4) successfully for months.  Note that all these ports
were built from up-to-date source per the excellent FreeBSD ports system
meta-structure, ditto the FreeBSD 8.2-STABLE operating system.

I had followed the README that came with this Perl web application
(which was not in the ports tree, but came as a tar file) to configure
apache2 and mod_perl2.  Everything was fine and ran smoothly.  Then I
did the June 9th upgrade, and after the build of almost all my ports
was complete, I attempted to launch apache2.  This failed.  :-(

Since I got a strange error from apachectl(8) I immediately suspected
the newer versions of either apache2 (2.1.9) or mod_perl2 (2.0.5).  I
had also upgraded to Perl 5.14 from the prior 5.12.3 version I had
been running up until June 9th, but I didn't suspect Perl 5.14 until
later.

When I asked the developers of the Perl application about this error,
they were clueless.  I was led to suspect something in their code base
after running down several suggestions both local and from various
mailing lists.  When the dust settled, and since I have neither the
time nor the expertise to debug the issue with any of these large
packages (apache2, mod_perl2, Perl, this Perl web application), I made
the reluctant decision to completely redo my June 9th upgrade but this
time moving back to Perl 5.12.3 to see if that one change would help.

As I have reported to those venues attempting to assist me, this
upgrade was successful.  Note that the only thing that changed in this
upgrade was the version of Perl.  The apache2, mod_perl2 and the Perl
web application were identical to the June 9th upgrade.  In fact, not
one thing had changed with the Perl web application since March 2011.

The way the FreeBSD ports system operates, one can use pre-built
binaries, or one can build ports from source, or a mixture of both.
I always (re-)build from source (including the operating system),
even when this may seen unnecessary.  I do this infrequently enough
that the burden is acceptable, but I do it often enough to ensure my
system has no known security risks.  However, I did not plan to do
two ground-up rebuilds within a two week period!

This experience (and some issues I had with one other FreeBSD port)
made me suspect Perl 5.14 (or perhaps, the side effects in other
code bases that use Perl caused by changes found in Perl 5.14).  It
may take several months for all the affected software packages to
migrate to being compatible with Perl 5.14 but I am happy to remain
at Perl 5.12.3 for the foreseeable future since everything works.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Wed, 06/29/11 at 14:04:
 
 My apologizes, I didn't mean to imply that you were inexperienced
 overall, but it seemed like you didn't have much experience with
 setting up mod_perl apps, specifically with startup.pl.  Or whomever
 built the app you were installing didn't put the startup.pl program
 together like it is recommended in the docs.

No need to apologize.  I just wanted to clarify for any who joined
in the thread late.

The application in question has no startup.pl file.  It is a Mason
based web application and starts with an index.html file that has
embedded Perl code.  I have only been working with this application
for a few months, and due to its large size (92 MB deployed), I have
yet to understand all aspects of it.  Not only am I new to mod_perl2,
I am also new to Mason, sigh...   :-(

 It looked like we kind of lost the 2.0.6-dev/5.14 aspect of that
 thread too, and after running 5.14 with 2.0.6 for a month or so now, I
 haven't run into any compatibility issues there.

I was advised (by you?) to try mod_perl2 (2.0.6) just to see if 2.0.5
was at fault.  I did and it wasn't.  I am leaning toward some Perl 5.14
issue that exists within this large Perl web application.  I have asked
the developers there to try running their application under Perl 5.14
and have yet to hear any feedback on that suggestion.  YMMV.

BTW, several other Perl based web applications I have written are built
on CGI::Application and do have what you call a startup.pl file although
those (short) files are rarely, if ever, called startup.pl.  Maybe I
need to read more about the mod_perl2 experience.  :-)

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Perrin Harkins per...@elem.com on Tue, 06/21/11 at 11:57:
 
 Maybe I'm the one confused now, but I thought you said that when you
 removed that the application started and those errors about the
 modules went away.  You said that instead you got errors about
 unreferenced scalar stuff when apache shut down.  Have you checked
 to see if the application works at that point?

I may have mis-spoken.  A lot of different tests and hair pulling here...

When the -compile parameters are removed, I get this:

   Syntax OK.
   Attempt to free unreferenced scalar: SV 0x28be1014 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28bda578 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28bda7d0 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28d1b3e8 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28d1b050 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28bda730 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28bda4b0 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28d1b3d4 during global destruction.
   Attempt to free unreferenced scalar: SV 0x28be176c during global destruction.
   Attempt to free unreferenced scalar: SV 0x28bda6cc during global destruction.
   Attempt to free unreferenced scalar: SV 0x28be15dc during global destruction.

and the server does not start.  I am becoming more and more convinced
that I will have to revert to 5.12.3 version of Perl...

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

 line from the Apache configuration 
 file (or comment it out)
 - add the above PerlRequire line to your Apache configuration
 
 The fundamental effect should be the same, but the perl language use 
 directive allows for additional parameters such as -compile, while this 
 is less than certain for the Apache/mod_perl PerlModule configuration 
 directive.
 
 (*) for example, it means that in all other perl programs, modules, scripts 
 running under your Apache/mod_perl, you can now use :
 
 return OK;
 
 instead of the longer
 
 return Apache2::Const::OK;

I am still at a loss as to how to proceed.  Ignoring the Apache2::Const
and APR::Const issues, the apache2 server still fails to start.  And I
don't know how to track down the problem.  Changing Loglevel to debug
in the httpd.conf file did not result in any errors logged to my apache
error log file (since the server failed to run).  Is this still a Perl
problem or could it be a mod_perl2 problem?  And how to debug it?

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Thu, 06/16/11 at 13:56:

 Hmm, odd that it wouldn't work under 2.0.5 but it would under 2.0.4.

I have spent some time today looking at the change logs for both
mod_perl2 and apache2 to see what, if anything, might point to a
change that could have produced my current problem.  I found none.

I originally thought based on this error output from apachectl -t:

   [Mon Jun 13 10:16:15 2011] [error] syntax error at (eval 21) line 1, near 
require Apache2::Const -\n
   [Mon Jun 13 10:16:15 2011] [error] Can't load Perl module Apache2::Const 
-compile = ':common' for server localhost:80, exiting...

that the problem stemmed from the first of these two lines:

   PerlModule Apache2::Const -compile = ':common'
   PerlModule APR::Const -compile = ':common'

which are found inside a *.conf file in the Includes directory of apache2.

BTW, these two lines are the only two lines in the entire source tree
of the application in question that contain the string :common.  But
since I am merely trying to launch the apache server, the Perl application
has not come into play yet, except for the parsing of the httpd.conf
file and the above mentioned include file found in the Includes directory.

When I comment out the first line, I get a similar error, but this time
it mentions the second line:

   [Fri Jun 17 12:17:41 2011] [error] syntax error at (eval 21) line 1, near 
require APR::Const -\n
   [Fri Jun 17 12:17:41 2011] [error] Can't load Perl module APR::Const 
-compile = ':common' for server localhost:80, exiting...

When I comment out the second line, I get this output on the console:

freebsd# apachectl -t
Use of uninitialized value in lc at 
/usr/local/lib/perl5/site_perl/5.14.0/Class/DBI.pm line 196.
Syntax OK
Attempt to free unreferenced scalar: SV 0x28bda050 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be05b4 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be080c during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1c21c during global destruction.
Attempt to free unreferenced scalar: SV 0x28d19e60 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be076c during global destruction.
Attempt to free unreferenced scalar: SV 0x28be04ec during global destruction.
Attempt to free unreferenced scalar: SV 0x28d1c208 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda7a8 during global destruction.
Attempt to free unreferenced scalar: SV 0x28be0708 during global destruction.
Attempt to free unreferenced scalar: SV 0x28bda618 during global destruction.

BTW: ignore the DBI error since that occurred when starting apache prior
to my system upgrade last week.

So the syntax is now okay, but something else breaks and the server fails
to start.  It seems like there is something wrong with the handling of the
PerlModule directive.  For example, is require parsing different from
use parsing?

I don't see how anything I have done, or the application that worked before
the upgrade, could be at fault here.  Something in apache2 or mod_perl2 or
their APIs has changed, perhaps related to the newish Perl 5.14 version.

I don't know how to approach this other than by asking the mailing lists
for some guidance.  Thanks for your help.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 13:43:

 On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu wrote:
  I have Perl 5.14 compiled from source.
  I have apache 2.2.19 ?compiled from source.
  I have mod_perl2 2.0.5 compiled from source (with these patches):
 
 Can you pull 2.0.6-dev from svn and build?
 
 http://perl.apache.org/download/source.html
 
   % svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
 mod_perl-2.0

I will certainly attempt to do so.  Stay tuned...  ;-)

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to James B. Muir james.b.m...@hitchcock.org on Fri, 06/17/11 at 
13:29:
 
 Have you checked the permissions on the Const.pm module?

freebsd% ls -l /usr/local/lib/perl5/site_perl/5.14.0/mach/APR/Const.pm \
/usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm \
/usr/local/lib/perl5/site_perl/5.14.0/mach/ModPerl/Const.pm
-r--r--r--  1 root  wheel  23410 Jun 10 17:08 
/usr/local/lib/perl5/site_perl/5.14.0/mach/APR/Const.pm
-r--r--r--  1 root  wheel  25924 Jun 10 17:08 
/usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm
-r--r--r--  1 root  wheel   3080 Jun 10 17:08 
/usr/local/lib/perl5/site_perl/5.14.0/mach/ModPerl/Const.pm


Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 13:44:

 On Fri, Jun 17, 2011 at 12:34 PM, William Bulley w...@umich.edu wrote:
  ? PerlModule Apache2::Const -compile = ':common'
  ? PerlModule APR::Const -compile = ':common'
 
 That syntax used to work?  It seems unlikely.  I've never seen a
 PerlModule call with options like this before.  I'd expect it to work
 without the -compile = ':common' stuff.
 
 This sort of thing usually goes in a startup.pl, not inside
 httpd.conf.  It's easier to manage there and things don't get pulled
 into surprising namespaces.

Yes.  Yes.  Yes!  :-)

This is what is so consternating for me to grok.

Others have suggested that I strip the parameters - I did and no change.

Others suggested I place the module(s) invocation inside (the existing)
Perl.../Perl tags - I did and no change.  Go figure?

Those two Const -compile lines were not in the httpd.conf file.

They were in an included *.conf file in the Includes directory
which might be the same thing, but I'm a pedantic sort of guy...  :-)

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 14:24:
 
 Have you tried making a startup.pl and calling these from there with use() ?

Recall that all I'm trying to do at this point is to get the apache
server up and running.  The fact that these two lines in this include
file of this particular application case apachectl -t to error out
should have nothing to do with the application and how it does or does
not start up.

Are you saying that a suitably constructed startup.pl file with these
two lines included would be useful to debugging this problem?  If so,
then what all does one need in a standard startup.pl, for example, that
I could use as a model?  Thanks.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 13:43:

 On Fri, Jun 17, 2011 at 10:29 AM, William Bulley w...@umich.edu wrote:
  I have Perl 5.14 compiled from source.
  I have apache 2.2.19 ?compiled from source.
  I have mod_perl2 2.0.5 compiled from source (with these patches):

 Can you pull 2.0.6-dev from svn and build?

 http://perl.apache.org/download/source.html

   % svn checkout https://svn.apache.org/repos/asf/perl/modperl/trunk/
 mod_perl-2.0

I have just built/installed mod_perl-2.0.6 (not sure about the dev part)
and tried again to start the apache server (using # apachectl -t):

   [Fri Jun 17 16:05:58 2011] [error] syntax error at (eval 21) line 1, near 
require Apache2::Const -\n
   [Fri Jun 17 16:05:58 2011] [error] Can't load Perl module Apache2::Const 
-compile = ':common' for server localhost:80, exiting...

This is very frustrating...  :-(

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Fri, 06/17/11 at 16:22:

 I think Perrin is right, I've never seen -compile syntax used in
 PerlModule directives.  Move the PerlModule directives into a
 startup.pl file.
 
 In your httpd.conf:
 
 LoadModule perl_modulemodules/mod_perl.so
 PerlPostConfigRequire /my/startup.pl
 
 In your startup.pl:
 
 #!/usr/bin/perl
 
 use strict;
 use warnings;
 
 # make sure we are in a sane environment.
 $ENV{MOD_PERL} or die GATEWAY_INTERFACE not Perl!;
 
 use Apache2::Const -compile = ':common';
 
 ... add any other PerlModule statements in the 'use Module' format.

Fine.  But what has this got to do with the inability of the apache
server to start?  These PerlModule directives are not my idea.  They
came with the application in question (to which I am trying to get).

Once I get the apache server running, I can deal with issues like
this one.  BTW, the application in question does not have a startup
file, it just has an index.html file and uses Mason, but that is
neither here nor there as far as this problem is concerned.

Recall that with these two Const -compile lines commented out
of that include file, the syntax phase of apachectl -t succeeds,
but the server does not start, and a bunch of other errors appear.

This, to me, sounds like an issue between apache2 and Perl 5.14 or
between mod_perl2 and Perl 5.14, but I don't really have any clue.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Perrin Harkins per...@elem.com on Fri, 06/17/11 at 15:35:

 On Fri, Jun 17, 2011 at 3:20 PM, William Bulley w...@umich.edu wrote:
  Recall that all I'm trying to do at this point is to get the apache
  server up and running. ?The fact that these two lines in this include
  file of this particular application case apachectl -t to error out
  should have nothing to do with the application and how it does or does
  not start up.
 
 Well, presumably they compile constants that your code needs.  But I
 see that you tried commenting them out, which is a good idea, and then
 got some unreferenced scalar errors, which were not related to these
 lines.
 
 I'd probably try stripping down your conf file to try to find what
 causes these errors, taking out chunks of mod_perl-related stuff until
 it starts without complaint.

Excellent suggestion!  Thanks!   :-)

This is where I will pick up the reins when I next return to this
effort.  I'll report back here what I find out.  Thanks again.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

apache2 or mod_perl2 oddball error

[William Bulley]

I'm not sure this is the best place to ask about this problem, and
this is my first posting to this mailing list.  I have already asked
the freebsd-questions mailing list about this, but have received no
replies as of this writing.

I'm running FreeBSD 8.2-STABLE #0: Thu Jun  9 09:25:05 EDT 2011 on i386
and I rebuilt all my ports from source shortly after the upgrade.  I got
a weird error when I tried to start apache2 (using % apachectl -t first):

   [Mon Jun 13 10:16:15 2011] [error] syntax error at (eval 21) line 1, near 
require Apache2::Const -\n
   [Mon Jun 13 10:16:15 2011] [error] Can't load Perl module Apache2::Const 
-compile = ':common' for server localhost:80, exiting...

The Perl module in question is present here:

   freebsd% ls -l /usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm
   -r--r--r--  1 root  wheel  25924 Jun 10 17:08 
/usr/local/lib/perl5/site_perl/5.14.0/mach/Apache2/Const.pm

The httpd.conf file is unchanged and was working since from before
the upgrade.

In the /usr/local/etc/apache22/httpd.conf file are these lines among
several hundred other lines:

   LoadModule perl_module libexec/apache22/mod_perl.so
   Include etc/apache22/Includes/*.conf

The only reference to the Apache2::Const module is in an Apache
config include file:

   PerlModule Apache2::Const -compile = ':common'

I have these FreeBSD ports installed among several hundred others:

   perl-5.14.0
   apache-2.2.19
   ap22-mod_perl2-2.0.5,3

Neither of these two commands gave any output at all:

   freebsd% perl -e 'use Apache2::Const qw( :common );
   freebsd% perl -M'Apache2::Const -compile = qw(:common)' -e 1;

This command gave one line of output:

   freebsd% perl -MApache2::Const -e 'print $Apache2::Const::VERSION, \n';
   2.05

The above problem did not occur before the upgrade when I was running:

   perl-5.12.3
   apache-2.2.17_1
   ap22-mod_perl2-2.0.4_2,3

I don't know how to debug this problem.  No log files in /var/log were
changed by running the apachectl(8) command and there have been no new
lines added to /var/log/httpd-error.log since I rebooted and shut down
apache2 on June 9th as part of the upgrade.  Any and all ideas welcome.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: apache2 or mod_perl2 oddball error

[William Bulley]

According to Fred Moyer f...@redhotpenguin.com on Thu, 06/16/11 at 13:56:
 
 Hmm, odd that it wouldn't work under 2.0.5 but it would under 2.0.4.

My point exactly...   :-(

 No idea why offhand.  Do you use a startup.pl in your application?

No.  The application's URL points to a directory with Mason laden HTML
files starting with index.html.  Why do you ask?

  Neither of these two commands gave any output at all:
 
  ? freebsd% perl -e 'use Apache2::Const qw( :common );
  ? freebsd% perl -M'Apache2::Const -compile = qw(:common)' -e 1;
 
 You need to call these statements in the context of a mod_perl interpreter.

Forgive me, but I don't understand what you mean.  :-(

Recall the error message:

freebsd# apachectl -t
[Thu Jun 16 14:29:15 2011] [error] syntax error at (eval 21) line 1, near 
require Apache2::Const -\n
[Thu Jun 16 14:29:15 2011] [error] Can't load Perl module Apache2::Const 
-compile = ':common' for server localhost, exiting...

I have just searched the entire application source hierarchy for the
string :common using the find(1) command.  The only file that contains
that string is the apache Includes file which has not changed since my
system upgrade.  Here are several of the lines in that file:

   #begining of file
   PerlModule ModPerl::Util
   PerlModule Apache2::Request
   PerlModule Apache2::RequestRec
   PerlModule Apache2::RequestIO
   PerlModule Apache2::RequestUtil
   PerlModule Apache2::ServerUtil
   PerlModule Apache2::Connection
   PerlModule Apache2::Log
   PerlModule Apache::Session
   PerlModule APR::Table
   PerlModule ModPerl::Registry
   PerlModule Apache2::Const -compile = ':common'  ===
   PerlModule APR::Const -compile = ':common'  ===

   PerlModule Apache2::SiteControl
   PerlModule HTML::Mason::ApacheHandler

   # Uncomment this next line if you get errors from libapreq2
   # about an 'undefined symbol'
   # LoadModule apreq_module /usr/lib/apache2/modules/mod_apreq2.so
   LoadModule apreq_module /usr/local/libexec/apache22/mod_apreq2.so
   .
   .
   .

Later in this file (and elsewhere in the application) there are uses of,
and references to, Apache2::Const, but there are no references to the
APR::Const module.  I have tried commenting these lines out and tried
removing the trailing parameters.  In some of the many permutations of
these two lines, I get a successful parsing of the httpd.conf file, but
likely that is because I commented out the entire line.  However, in
these cases, I get a dozen error lines like this one:

   Attempt to free unreferenced scalar: SV 0x28bda050 during global destruction.

In no case do I get a successful launch of the apache server, nor do
I get any lines in the httpd_error.log file.  Any other ideas?

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: Ubuntu and mod_perl

[William A. Rowe Jr.]

On 5/17/2011 3:39 PM, Tom Kane wrote:
 I'm still a little new at responding to mail lists. Here is an email that I 
 sent directly in a reply to Marco. I thought that it should be shared:
 
 Marco,
 
 I had to do the following just the other day:
 
 sudo ln -sf /usr/lib/libperl.so.5.10.1 /usr/lib/libperl.so
 
 That got me over the hurdle that occurred because of the missing symbolic 
 link to perl. I also had to do the following:
 
 sudo ln -sf /usr/lib/libgdbm.so.3.0.0 /usr/lib/libgdbm.so
 
 The libgdbm issue actually occurred prior to the perl problem.
 
 I hope this helps. I am now trying to find the settings for mod_perl in the 
 /etc/apache2 configuration. My startup.pl file returns an error message that 
 I can't use 'use'.

Tom, it seems you are missing gdbm-devel and perl-devel packages.  To get
the appropriate .a/.so/.h files, you usually have to add -devel (or -dev)
flavors of various system components to build new software against them.

Re: failure to build Apache2::Request

[William Bulley]

According to Joe Schaefer joe_schae...@yahoo.com on Sun, 01/30/11 at 12:36:
 
 FreeBSD has a port for www/p5-libapreq2

THANK YOU!   :-)

I had looked for Apache2 and Request (case sensitive) in /usr/ports and
finding none was forced to consider CPAN modules.  I would have never
thought to have looked for (lowercase) libapreq2 - in fact the number
of www/p5- ports in FreeBSD with all lowercase names is less than ten
(10!) and this is an up-to-date (8.2-PRERELEASE) system - go figure...  :-)

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

failure to build Apache2::Request

[William Bulley]

According to Issac Goldstand mar...@beamartyr.net on Thu, 01/27/11 at 13:59:

 It looks like it's missing .h files from mod_perl...  Might I suggest
 you post this question (with the build output) to
 modperl@perl.apache.org?  There are some people there who knwo mod_perl
 better than myself who might be able to quickly figure out what's wrong...
 
   Issac
 
 On 27/01/2011 20:40, William Bulley wrote:
 
  According to Issac Goldstand mar...@beamartyr.net on Thu, 01/27/11 at 
  13:37:
  
   I must have missed that bit, but yes, it does need mod_perl (unless you
   want to disable the Perl glue, which judging by your getting it from
   CPAN, I assume you want).  The reason is that the APR C library Perl
   glue, needed by the apreq Perl glue (aka Apache2::Request) is bundled in
   mod_perl 2
 
  I don't understand everything you say above.  I was forced to use CPAN
  since there was no Apache2::Request port on my FreeBSD workstation.
 
  I ended up building mod_perl2 and things seemed to work better with
  respect to installing Apache2::Request via CPAN.  Yet it still errors
  out (see the attachment I last sent you).  I need to build Apache2::Request
  so I can build other Perl modules that depend on it (and the application
  which depends on all these and more).  What do I need to do to get the
  CPAN module to build correctly?  The needed file is there, but the INC
  chain is missing the full path to that include file.  I don't know if
  I should change the *.c (or *.xs in this case) source file, of somehow
  change the Makefile so that the correct path is included in the INC
  make variable.  Your advice is urgently sought!  Thanks.   :-)

I have attached the complete build log for Apache2::Request which shows
the failure (near the end) to compile Request.c due to an incorrect INC
path for an include file that does exist, but not where the Request.xs
file thinks it is (using a #include file.h statement).

This is on FreeBSD 8.2-PRERELEASE with the following ports in place:

   ap22-mod_perl2-2.0.4_2,3
   apache-2.2.17_1

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|

Re: experiencing Out of memory errors

[William A. Rowe Jr.]

On 1/27/2011 7:16 PM, Michael Peters wrote:
 On 01/27/2011 07:41 PM, Michael Ludwig wrote:
 Michael Peters schrieb am 27.01.2011 um 19:14 (-0500):

 But, even after all that I have applications where we consistently
 run 3-4G just for mod_perl/Apache.

 But surely not in one process as the OP said he'd like to do?
 
 No you're right, but I'm guessing he might be running a threaded MPM, so 
 single process,
 multiple threads.

Exactly.  Even constraining httpd to smaller stacks is unlikely to be wise
with mod_perl running, consider the default is 256kb IIRC.  Shrinking this
to 128k obviously is a big help, but is unrealistic.

I agree with Peters, run a proxy in front of the server hosting mod_perl.
Even when we ship binary 64 bit for win32, there are far too many broken
perl and similar modules which don't expect sizeof(long*)  sizeof(long),
which has tripped up many porters.  Most of these defects are gone from
apr and httpd, and perl and modperl can likely catch up quickly, but to
isolate every possible modperl XS package on cpan and identify all those
which make stupid long x = (long)xptr; assignments will be arduous.

Re: huge apache+mod_perl processes

[William T]

If you don't have an unbounded growth issue it is likely do to some
library pulling in alot of dependencies or the creation/caching in
memory of some large data structure.  You can preload all the
offending libraries and see if that causes a jump in the initial
memory allocation for you apache procs.  If not you can create a
Handler that fires during cleanup/log phase to capture memory size
right after each access.

2010/9/29 Eugene Toropov j...@aaanet.ru:
 Greetings,

 We have a problem with huge Apache+mod_perl2 processes of 150-200 Mb in
 size. After apache restart they are usually 40-50 Mb in size, then in a
 minute grow up to 100-150 Mb and then some time later may grow up to 200 Mb.
 I suspect a certain type of http queries and would like to know if there are
 any manuals/howtos/tools to investiagate such cases.

 # perl -v
 This is perl, v5.10.1 (*) built for x86_64-linux
 # strings /usr/local/apache2/modules/mod_perl.so | grep mod_perl\/
 mod_perl/2.0.4
 # /usr/local/apache2/bin/httpd -v
 Server version: Apache/2.2.14 (Unix)

 # pmap -x 8320
 8320:   /usr/local/apache2/bin/httpd -DSSL
 Address   Kbytes RSS   Dirty Mode   Mapping
 0040 584 496   0 r-x--  httpd
 00692000  24  20  20 rw---  httpd
 00698000  12   8   8 rw---    [ anon ]
 17c1  147640  144612  144608 rw---    [ anon ]
 
   --  --  --
 total kB  352380  156560  151324

 # /usr/local/apache2/bin/httpd -l
 Compiled in modules:
   core.c
   mod_authn_file.c
   mod_authn_default.c
   mod_authz_host.c
   mod_authz_groupfile.c
   mod_authz_user.c
   mod_authz_default.c
   mod_auth_basic.c
   mod_include.c
   mod_filter.c
   mod_log_config.c
   mod_env.c
   mod_setenvif.c
   mod_version.c
   prefork.c
   http_core.c
   mod_mime.c
   mod_status.c
   mod_autoindex.c
   mod_asis.c
   mod_cgi.c
   mod_negotiation.c
   mod_dir.c
   mod_actions.c
   mod_userdir.c
   mod_alias.c
   mod_rewrite.c
   mod_so.c
 #
 Cheers
 Eugene

Re: Secure web

[William T]

This is very big question.  You should research perl best practices
for development.  You should also research secure programming
techniques.

On Sun, Oct 3, 2010 at 4:36 PM,  adi.yat...@gmail.com wrote:
 Hai,
 I am new to mod_perl.
 I want to build secure web based applications (not https), I mean secure 
 agains hacker.
 What is the options if I want to build it with mod_perl?

 Sorry for my bad english.

 Regards from Indonesien,
 Adi
 Sent from my BlackBerry®
 powered by Sinyal Kuat INDOSAT

Re: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/27/2010 6:09 AM, Peter Janovsky wrote:
 Are you returning the value of 200 within a module you've written?  I 
 encountered a
 similar issue within a C module specific to valid requests. It was resolved 
 by returning
 the internal constant OK. 

This is a generalized issue of serving ErrorDocuments; if they have a Status/
result code update (such as a backend proxy response or a cgi response), that
will override the original error code.  c.f.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49996

So it is not strictly a bug, but you certainly aren't the first to be frustrated
by the behavior; look to the manner you handle ErrorDocuments with, first.

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/28/2010 12:25 AM, Nico Coetzee wrote:
 The status 400 (with $r-status_line) produces the same result HTTP/1.1 200 
 OK and with
 ($r-status) is creates a HTTP/1.1 400 Bad Request (the custom string gets 
 lost)
 
 The $r-status with a code of 499 produces a HTTP/1.1 400 Bad Request

Sort of confirms my theory.

Set status to 400 and set status_line to 400 Custom Message, see what happens?

I suspect that 499 simply isn't allowed, which is wrong, but the current
behavior none the less.

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

On 9/28/2010 1:32 AM, Nico Coetzee wrote:
 and... it works now !!

I'd hit the same bug from CGI some half-decade ago, sorry I didn't
see where the problem was in the first place :(

Re: Fwd: All responses are 200 (server error)

[William A. Rowe Jr.]

Two thoughts...

try status 400 (might be special handling for 4xx unknown)

try r-status instead of/in addition to just r-status_line?

Re: Bucket Heap? Error?

[William A. Rowe Jr.]

On 6/25/2010 4:54 PM, Dos Wizard wrote:
 Hello,
 
 I can't make mod_perl to work with httpd-2.2.15
 While everything is ok, I get this annoying error whatever I had tried yet 
 (e.g. read the docs and follow the installation steps accurately)
 
 Currenlty I am using a custom compiled Perl5.12.1 which had NO problems 
 during the installation (it had passed all the tests successfully), and so on 
 with additional modules, etc.
 
 Now, when I try mod_perl I get this:
 
 /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: 
 /usr/src/httpd-2.2.15/srclib/apr-util/.libs/libaprutil-1.a(apr_buckets_pool.o):
  relocation R_X86_64_32S against `apr_bucket_type_heap' can not be used when 
 making a shared object; recompile with -fPIC 
 /usr/src/httpd-2.2.15/srclib/apr-util/.libs/libaprutil-1.a: could not read 
 symbols: Bad value collect2: ld returned 1 exit status

Recompile *PERL* -fPIC - it can't relocate the perl code.

Re: modperl and comet?

[William A. Rowe Jr.]

On 4/16/2010 3:37 PM, E R wrote:
 I'm interested in adding a Comet capability to a (rather large)
 mod-perl application.
 
 To get around XSS limitations, the Comet service will have the same
 host and port as the web service. However, I don't want a large
 mod-perl process tied up performing the Comet service.
 
 Is there a way that a web request can be passed off to another process
 without tying up the Apache process? For instance, can the Apache
 process pass the file descriptors for the HTTP connection to another
 process which would free itself up for handling the next Apache
 request?

That should become a goal of event mpm, but right now event's only purpose
is to unhook the worker between the requests on keepalive connections.

Re: mod_perl memory

[William T]

On Mon, Mar 15, 2010 at 11:26 PM, Pavel Georgiev pa...@3tera.com wrote:
 I have a perl script running in mod_perl that needs to write a large amount 
 of data to the client, possibly over a long period. The behavior that I 
 observe is that once I print and flush something, the buffer memory is not 
 reclaimed even though I rflush (I know this cant be reclaimed back by the OS).

 Is that how mod_perl operates and is there a way that I can force it to 
 periodically free the buffer memory, so that I can use that for new buffers 
 instead of taking more from the OS?

That is how Perl operates.  Mod_Perl is just Perl embedded in the
Apache Process.

You have a few options:
  * Buy more memory. :)
  * Delegate resource intensive work to a different process (I would
NOT suggest a forking a child in Apache).
  * Tie the buffer to a file on disk, or db object, that can be
explicitly reclaimed
  * Create a buffer object of a fixed size and loop.
  * Use compression on the data stream that you read into a buffer.

You could also architect your system to mitigate resource usage if the
large data serve is not a common operation:
  * Proxy those requests to a different server which is optimized to
handle large data serves.
  * Execute the large data serves with CGI rather than Mod_Perl.

I'm sure there are probably other options as well.

-wjt

Fwd: Killing oversized Perl processes

[William T]

On Thu, Mar 11, 2010 at 1:41 PM, ARTHUR GOLDBERG a...@cs.nyu.edu wrote:

 OK, that kills big processes. What happens next is that Perl runs out of
 memory (outputs Out of Memory!) and calls the __DIE__ signal handler. So,
 my plan is to catch the signal, redirect the browser to an error page, and
 finally kill the process. Before the http Request handler is called I say:

Too complicated.  Use Apache2::SizeLimit.  It runs as a cleanup
handler which means your user will have gotten served, and then the
child will die.  You can also write your own cleanup handler to
monitor sizes and if you want without having to do anything like
catching a __DIE__.

 Thus, my question is: how can one kill an oversized process and provide
 feedback to the user at the browser?

In general kill during cleanup phase.  Apache2::SizeLimit does just that.

I would also argue that you should probably fix your memory leaks.
Sometimes all it takes is a few days of analysis.  That's what
happened with me.

You can also segment out functionality to different Apache servers so
that every Apache/mod_perl child does not have to pull in the entire
code base for the website.

-wjt

Re: output filter

[William T]

On Thu, Jan 28, 2010 at 11:46 PM,  m...@normalperson.e4ward.com wrote:
 BTW, though we are still using modperl for developing some applications.
 But it seems other instead technologies are becoming more and more
 popular, like PHP,Django,Rails etc.
 Is modperl  outdated in today?

I don't know that PHP is becoming more popular, I think it's
popularity is actually waning.  While Django, and Rails are certainly
popular, I don't think it necessarily follows that modperl is
outdated.  It certainly performs better than Django and Rails, but
that isn't necessarily a hard requirement for many places.  It's
probably more of business decision these days.  Which technology do
your employees know the best, and what's the availability of people
who know that technology in the job market?  The pluses and minuses to
each language and technology mostly even out.  Chances are if you are
writing webapps your not really going to run across large
differentiating factors between the technologies.

-wjt

Re: 302 Redirect not working as expected with PerlCleanupHandler and Firefox under ModPerl::Registry

[William T]

Caveat Lector:

Long Cleanups done inline on the Apache children can cause problems.

If you get a situation where the CleanUp takes to long OR you get
enough traffic to the page(s) which engage the CleanUp then you will
encounter a tipping point, and soon after your website will be almost
completely unavailable.  This will occur because the Apache Children
aren't processing requests fast enough to handle the rate at which the
come in; because they are busy in CleanUp.

The reason I bring this up is encountering the failure is usually a
catastrophic event.  The website is almost always entirely down, and
workarounds can be hard to come by.

This may or may not apply to you depending on your traffic
characteristics and how long your cleanup takes, BUT it is something
you should be aware of.

-wjt

Re: Apache Blank Pages

[William T]

It seems pretty clear the blank pages are from the apache children dieing
badly (hence the errors).  I would make an educated guess based on the
malloc error that your ram is bad.  Try running your app on a different box
and see if you get the same errors.

On Jan 12, 2010 7:19 AM, cfaust-dougot cfa...@doyougot.com wrote:

 Hello,

I have a bizarre problem I'm hoping someone could give me some suggestions
with.

I have a couple of MP2 scripts running on a server, they are both similar in
use of modules and structure. Without any recent changes, one of the scripts
is producing a blank apache page on SOME requests.

It's not always the same function, it can happen to any of the function
calls contained in the script.

When the blank page happens there is nothing in either the access log or the
error log of that virtual host (like the request never made it that far).

In the default error log I will get something like

[notice] child pid 11497 exit signal Aborted (6)

Sometimes (but not always), I'll see

*** glibc detected *** malloc(): memory corruption: 0x09c120f8 ***

 There is also no consistency to the blank page, sometimes you hit the URL
and you get the content, sometimes you get a blank page, sometimes 1 refresh
on the blank page gives you content, other times it can take 3 - 7 refreshes
before the content comes.

I've been trying to pull apart my script piece by piece in the hopes that I
could at least narrow it down to some specific section but I'm not having a
lot of luck.

Any thoughts on how I could debug this better?

TIA!

Re: modperl / apache13 memory footprints on 32 adn 64 bit servers

[William A. Rowe Jr.]

Joe Niederberger wrote:
 Does anyone know if one can have 64bit perl use 64 bit addressing (to make
 use of 4GB RAM) but still use 32-bit INTs etc (to keep footprint from
 getting
 large)?

This is the default on windows x64.

Re: avoiding child death by size limit

[William T]

On Thu, Dec 10, 2009 at 11:28 AM, E R pc88m...@gmail.com wrote:
 Hi,

 I have a problem where a mod_perl handler will allocate a lot of
 memory when processing a request, and this causes Apache to kill the
 child due to exceeding the configure child size limit.

 Are there any special techniques people use to avoid this situation?
 Does SizeLimit count actual memory used or does it just look at the
 process size?

You can make sure the variables that the memory was malloc'd for have
gone out of scope, and there are not trailing references to them.
Perl will then reuse that memory.  Occasionaly Perl will free memory
it's not using, but why, where and when can be hard to determine.
It's not always as clear cut as undef'ing the variable.

In terms of managing memory in your mod_perl process you can use any
of the standard techniques:

  * change/fix the code (fix memory leak, Tie structure to filesystem/db, ...)
  * recycle your children after N number of request are completed
  * offload the memory intensive work into a different process space
(another instance of Apache/mod_perl or even just Perl)
  * use a system set resource limit (not so good because it can kill
the proc mid-request)
  * Apache2::SizeLimit (kill the proc after it's done serving the
request when it grows too big)

These were off the top of my head.  THere may be other techniques I missed.

-wjt

Re: print throwing intermittent Segfaults

[William T]

This is the list of stuff I usually start with when I get a problem
that doesn't seem to be tied to a particular code path.

  * code path - perhaps a particular code path is only being exercised
rarely, and it has a bug
  * forking - when child dies, all open descriptors in it's name space
also get closed
  * eval - always a good thing to look at when weird things happen
  * persistancy - globals, closures, persistant objects,
serialized/restored objects, shared memory, shared objects (between
processes)

-wjt

Re: Why people not using mod_perl

[William T]

On Fri, Oct 23, 2009 at 4:06 PM, Ihnen, David dih...@amazon.com wrote:

 But I'm very interested to know at what point (if any) a site/app grows too
 large or too complex for mod_perl and what defines that turning point.
 Could Amazon run on mod_perl for example?

To me mod_perl is just a platform like most other web stacks.  As such
ANY webapp written with ANY webstack that is designed and built for
efficient horizontal scaling can be used.  Take into account how to
make the best use of a CDN, how to distribute database  load (probably
by partioning).

-wjt

Re: DBI Connectons accumulate under Mod_perl

[William T]

On Tue, Oct 20, 2009 at 9:59 AM, Artem Kuchin mat...@itlegion.ru wrote:

 however, whe i do in mysql

 show processlist;

 I see many connection hanging in sleep state and they grow and grow slowly!
 Any idea why this happens?

Could be many things.  Maybe multiple hits to different Apache
children are opening new DB connections before anyone of them finish.
If your experiencing slow page load as time goes on you may also have
table locking or row locking issues.

Or it could be that some code other than yours brings in Apache DBI.

I suggest turning on DBI debugging for a short while.

-wjt

Re: ApacheCon 2009 in Oakland

[William A. Rowe, Jr.]

Jeff Trawick wrote:
 On Mon, Oct 19, 2009 at 12:15 AM, Fred Moyer f...@redhotpenguin.com wrote:
 Greetings,

 Is anyone here attending ApacheCon in Oakland this year?  I am
 organizing a mod_perl social.  I'll be at the conference at least one
 day hacking mod_perl.
 
 This lurker will be there.

Sounds like a plan, would be good to know 2.0.5 is ready for httpd 2.4, or at
least something like it.  See you all there!

Re: Configuring virtual hosts on the fly

[William T]

On Sun, Oct 11, 2009 at 11:54 AM, Scott Gifford
sgiff...@suspectclass.com wrote:
 Hello,

 I'm working on an Apache configuration for a cluster of machines
 serving a variety of virtual hosts.

I would not try to unify disparate configs into one unless each server
is actually going to service all the virtual hosts your pulling in.
You would unnecessarily couple configs together that don't need to be.

 It seems much cleaner to me to let Apache look up the information for
 a virtual host as it is needed.  Conceptually, when each request comes
 in, I would like Apache to look at the Host: header, build a temporary
 virtual host entry from that, and use it to service the request.  I
 will use caching to make it reasonably fast.  Then the provisioning
 script just writes to the database table and is done, and I can handle
 any errors on a per-request basis without Apache failing to start.

Sounds like you might be pushing the envelope on what Apache can
actually do.  If you cannot solve the problem in Apache you could
consider relying on Apache default vhost as a way to funnel all
requests into a Perl dynamic vhost implementation.  You get exactly
what your looking for, but you tradeoff the speed and maturity of
Apache vhost code for yours.

-wjt

Re: Configuring virtual hosts on the fly

[William T]

On Tue, Oct 13, 2009 at 8:08 AM, Scott Gifford
sgiff...@suspectclass.com wrote:
 Sounds like you might be pushing the envelope on what Apache can
 actually do.  If you cannot solve the problem in Apache you could
 consider relying on Apache default vhost as a way to funnel all
 requests into a Perl dynamic vhost implementation.  You get exactly
 what your looking for, but you tradeoff the speed and maturity of
 Apache vhost code for yours.

 Thanks, I will definitely take a look!  Do you have any recommended
 reading on this, or just what Google turns up for dynamic vhost?

I don't know of anything that specifically does this, then again I
havn't looked.  I was mainly thinking about pushing the problem into a
different layer since I wasn't sure the Apache layer would work.  If
it were me I would probably start by looking for through Mass Dynamic
Virtual Hosting and make sure you can't solve your problem in the
Apache layer, or with a ModPerl Apache module to extend Apache (either
one already written, or one you write yourself).  Then move on to Perl
code that does webserving.

-wjt

Re: distributing software built on mod_perl

[William T]

On Fri, Sep 25, 2009 at 7:32 AM, Mike Barborak barbo...@basikgroup.com wrote:
 I think I see what you're saying. It seems like a very expensive
 problem to solve. It must be a barrier to people choosing mod_perl to
 develop their apps because it might be the case that their
 distribution and installation process is more complex to develop and
 support than their actual applications. That's what it's looking like
 in my situation and so I'm going to reevaluate using mod_perl.

It's not limited to mod_perl.  It's limited to any shrink wrapped
software.  It's less of an issue with software that can be self
contained versus software that is shared on the system.

 But it seems like there's a lot of generally repurposable results in
 your efforts that could make distributing mod_perl applications more
 straightforward. It seems like at the core of what you do is a massive
 distributable that contains:

 * mod_perl binaries
 * perl binaries
 * necessary perl module binaries
 * project-specific binaries

I would split up the distributable by platform since that is the
granularity you care about.

I usually rely on package that are already provided by various
distributions.  My target platforms are usually RedHat, Debian, and
FreeBSD which all have stable mod_perl+apache packages already, as
well as a significant number of perl packages available.  I then
backfill any packages which are not available for that distro so
really all I have to maintain is the difference between the packages I
use, and what the distributions already provide.

 This massive distributable contains these binaries built for all the
 supported platforms and all the supported versions of Apache. So if we
 say that there are on the order of 10 platforms that need to be
 supported to cover 95% of all installations and there are 5 versions
 of Apache to support (just guessing with both numbers), then it would
 be a matter of building:

 * 50 versions of the mod_perl binaries
 * 10 versions of the perl binaries (multiplatform installations
 supported by perl already)
 * 10 versions of the necessary perl module binaries (multiplatform
 installations supported by perl already)
 * 10 versions of the project-specific binaries

10 platforms seems a bit excessive, but then again it depends what
your counting as a platform.  ie.  RedHat/Debian, RHEL 4.2/4.3, or
RHEL 4/5.  If your platform is a distribution then your dependency
chain is different for each platform .  If your platform is minor
revision of a particular distribution, then it may not matter so much,
it's probably the same dependency chain.  If they are different major
versions, you can go either way depending on if it's common for both
major versions don't have too many differences in the dependency
chain.

In all cases though you want to leverage work already done by the
various distributions as well as third party package repositories to
reduce your own overhead.

 This would take a lot of effort to setup but doesn't seem unreasonable
 to maintain. And with this binary repository in hand then it seems the
 distribution problem really does become fairly straightforward; it's
 just a matter of figuring out the target platform and apache version
 and then producing an appropriate apache configuration snippet. That
 seems a lot easier than trying to walk a client through the process of
 getting the development version of apache, getting the necessary build
 tools, building mod_perl, building perl modules, etc. It also seems
 like it would make less of an impact on a client's existent system
 that replacing their web server.

It's a tradeoff of up front work to figure out which platforms your
going to support, and what that means in terms of your dependency
chain, versus an unknown dependency chain and trying to mitigate all
the variance you may encounter in your support calls.

That isn't to say you can't take a middle ground as well so long as
the risks are understood.  It may in fact be cost prohibitive to do
the right thing and track entire dep chains especially if your
trying to support a large number of platforms.  So the question
becomes what is good enough.  How much can you maximize number of
supported platforms while minimizing support risk?

 So is it a pipe dream to think that such a repository of
 non-project-specific binaries could be made publicly available to
 mod_perl application developers? Some of the problems I see are:

 * Have I captured all the variants or would you also have to build
 version for all the various versions of libc, mysql, etc.?
 * For customized perl modules and your own application, what would the
 resource be to build it on all the supported platforms? Perhaps this
 is where someone could monetize this scheme.

There is is the idea of following your dependency chain until it is
good enough versus following it all the way to libc versions and
kernel versions.  My rule of thumb is to only follow language/library
which is what I would consider prime 

Re: Why people not using mod_perl

[William T]

On Fri, Sep 18, 2009 at 1:34 AM, Clinton Gormley cl...@traveljury.com wrote:
 I'm surprised that nobody has mentioned EPIC, the Perl plugin for
 Eclipse.  It works really really well, at least as well as the Java
 version (although it can't do as much prediction as Java can because of
 the nature of static vs dynamic languages).

 The problem is necessarily dynamic vs static, but rather a language
 with a BNF compared to a language without.  By BNF I actually mean a
 set of rules by which to parse (BNF actually being the rules in a
 particular format).  Much of most modern IDE capabilities are hindered
 by not being able to parse the code.

 I am using Emacs for almost 20 years now but it lacks good XS support.

 Emacs has worked pretty well for me so far.  I tried other IDEs, and I
 found most of the to be clunky and too window based.  I find I'm most
 productive when I use Emacs.

 -wjt

Re: distributing software built on mod_perl

[William T]

Whenever I creating shrink-wrapped software I always make packaging
and distribution part of the development, qa and testing process.  All
packages for the platforms that we will be supporting.  The reason I
do this is to cut down on the customer support overhead.  I've found
you get less calls and emails regarding installation.  And more
importantly when it comes to supporting the customer they all have the
same installation per platform which often times makes things much
easier to debug (or at least removes alot of potential sources for
problems).

In practice what this means that we have an additional make target,
package which creates the appropriate package for the platform it's
running on.  I also have automated unit test which pull apart the
installation verifying meta data and install bits, as well as running
the installation in a sandbox to verify installation occurs without
issue.  It can be alot of upfront time to set this up, but very little
maintenance is required once it's up and running.

YMMV

-wjt

Re: Help -- how to fork an Apache process in mod_perl safely? Not Apache2:Subprocess...

[William T]

There are all kinds of problems that you'll encounter and have to solve if
you fork.  I found it's better to call at(1) to start another seperate
process immediatly.  If you need to pass data JSON worked really well for
me.

-wjt

On Aug 25, 2009 5:12 AM, Victor Danilchenko vic...@askonline.net wrote:

   Hi all,

   I need to be able to fork an Apache process in daemon form, to do
some housekeeping which might potentially take a few seconds. However, when
I do that, I start getting SQL errors (of the connection lost type) in the
browser. I do the fairly standard cleanup to daemonize the child process,
but of course it needs to retain the SQL socket open. Here is my forking
code:

sub modperl_kamikaze_fork () {
   # You will have to do CORE::exit(0) at the end of the execution.

   $SIG{CHLD} = 'IGNORE';
   get_m-flush_buffer;
   defined (my $kid = fork) or die Cannot fork: $!\n;
   return $kid if $kid;

   my $r = get_r;
   close STDIN; open STDIN, '/dev/null'
   or die Can't read /dev/null: $!;
   close STDOUT; open STDOUT, '/dev/null'
   or die Can't write to /dev/null: $!;
   close STDERR; open STDERR, '/tmp/form.log'
   or die Cannot open /tmp/fork.log\n;
   setsid
   or die Can't start a new session: $!;

   my $oldfh = select STDERR;
   local $| = 1;
   select $oldfh;
   warn Child (PID $$) spawned.\n;

   $r-child_terminate;
}


   The Apache2:Subprocess doesn't help me, because I need not to spawn
an external process, but to finish processing in mod_perl context -- just
without bugging the user with it.

   Any ideas on how to either fork better, or how to solve this without
forking (e.g. is there a way to 'append' a function call to the request
after the rest of the request is completed)?

   Many thanks in advance.

-- 
   Victor Danilchenko
   Senior Software Engineer, AskOnline.net
   vic...@askonline.net - 617-273-0119

Re: mod_perl on win32

[William A. Rowe, Jr.]

Michiel Beijen wrote:
 
 I'd like to know if it's possible to build mod_perl on Win32; I'd like
 to use mod_perl with StrawberryPerl. It seems to be that the only way
 that could be done is to compile Apache also with MinGW, and that's not
 possible because of limited support for Windows Shared Memory in MinGW.

There are various flaws in the build, report them to d...@httpd or collect
them in bugzilla reports, and mind the existing reports which might already
solve your problem.

Since there is no MinGW port maintainer, this often falls apart, sorry there
is nothing we can do if a platform's community does not participate with or
engage the developers with patches.

 Also if you'd try to compile mod_perl it will try to run ./configure
 on the Apache sources but that will fail on Win32 because 1. there is no
 Configure in the win32 Apache sources and 2. Windows will try to execute
 . which is not exactly an executable file...
 
 Does anyone have pointers or tips?

You don't use the -win32-src package because that package is for building
on the Microsoft Windows platform.  If you want to build for a faux-unix
platform you would obtain the usual tarball.

Re: Can a PerlAuthzHandler access ENV variables set by mod_auth_kerb?

[William T]

On Mon, Jul 6, 2009 at 10:14 AM, Mike Diehnm...@diehn.net wrote:


 Hello, all.

 I'm authenticating users with mod_auth_krb and setting KrbSaveCredentials
 to on.  I've found that the credentials are stored in a file in /tmp.  The
 name of the file is passed to CGI programs as the contents of an ENV var
 named KRB5CCNAME.

 I'm handling the authorization phase with a mod_perl2 PerlAuthzHandler
 script.  I want to use the credentials that mod_auth_kerb just verified.
 By this phase, the name of the credential cache file has been stored
 somewhere by mod_auth_kerb.

 The question is this:

   How can I get that filename?
   How can I read the ENV that will ultimately go to CGI scripts?

 PerlPassEnv seems not to do it.

On Mon, Jul 6, 2009 at 10:14 AM, Mike Diehnm...@diehn.net wrote:

 Hello, all.

 I'm authenticating users with mod_auth_krb and setting KrbSaveCredentials
 to on.  I've found that the credentials are stored in a file in /tmp.  The
 name of the file is passed to CGI programs as the contents of an ENV var
 named KRB5CCNAME.

 I'm handling the authorization phase with a mod_perl2 PerlAuthzHandler
 script.  I want to use the credentials that mod_auth_kerb just verified.
 By this phase, the name of the credential cache file has been stored
 somewhere by mod_auth_kerb.

 The question is this:

   How can I get that filename?
   How can I read the ENV that will ultimately go to CGI scripts?

 PerlPassEnv seems not to do it.

You need both PassEnv and PerlPassEnv.  Alternatively you may be able
to access the variable using subprocess_env.

http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_subprocess_env_

-wjt

Re: trying to add header field using PerlInputFilterHandler to proxy packets

[William T]

On Mon, Jun 29, 2009 at 8:07 PM, Brandon Allgoodallg...@numerate.com wrote:
 I am running an apache server 2.2.3 on CentOS 5.2.  I have turned on the
 proxy with the following lines from my apache.conf:

 IfModule mod_proxy.c
 ProxyRequests On
 Proxy *
 Order deny,allow
 Deny from all
 Allow from all
 /Proxy
 /IfModule

 I would like to add a header field to all requests going through the proxy.

If your adding a static header you can just use the Apache directive
'Header'.  Using mod_perl to add a static header is somewhat overkil.

-wjt

Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c

[William A. Rowe, Jr.]

Joe Orton wrote:
 
 Having thought about this longer, I do agree that it would be reasonable 
 to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it 
 turns out we're out of bits - allow_options_t is an unsigned char and 
 we're using 2^0 through 2^7 already. :(

The C langauge promotes char - int for comparison.  256 should work fine,
no?  It would devolve to 0, of course, but 256  255 should test fine.

Thoughts?

 The only available option is to #define OPT_INCNOEXEC to some bogus 
 string or something; not sure I like that much better than just a clean 
 break.

Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c

[William A. Rowe, Jr.]

Jeff Trawick wrote:
 
 Backing up a bit...
 
 I originally thought we could map bit values in 2.2.x to avoid affecting
 modules, but that isn't possible since includes-with-exec is two bits
 instead of one.

Hold on... I think this can still work;

  * Retain new true 'Includes' bit as old IncludesNoExec macro value
Keep ancient Includes flag bit as 256, never true.

  - all httpd modules testing for including but not executing
permission see the permission as allowed

  - old httpd modules testing for includes with exec permission
see the permission as denied, until they update the module

  - httpd modules which force/override the includes without exec
permission would still work

  - httpd modules which force/override the includes exec behavior
would just fail to update anything (256  0xff == 00), so it
becomes a noop until they update the module

So it has no negative security consequences, still would require
an update to the rare module, but lets us ship something without
really nasty side effects.

Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c

[William A. Rowe, Jr.]

Jeff Trawick wrote:
 Does somebody else care to share their opinion on this?  Which of these
 are okay?
 
 - existing mod_perl releases (and potentially other third-party modules)
 won't compile with 2.2.12

CORE_PRIVATE may be broken from release to release, it's a necessary
concession to prevent utter stagnation :(

I believe it was a mistake that this particular symbol/this particular
directive is not a part of the mod_includes internals :(

So given we have a .23 mmn bump, perhaps document this in that section.
But the actual behavior of this flag changes significantly and I can't
see how to properly maintain mod_perl, deep internal compatibility.

Re: Pass value from filter to anothe filter

[William T]

On Wed, May 13, 2009 at 3:09 AM, Idel Fuschini idel.fusch...@gmail.com wrote:
 PerlModule ::
 PerlTransHandler +::module1
 Location /xxx/*
     SetHandler modperl
     PerlInputFilterHandler ::module2
 /Location

 and I want to pass variable from module1 to module2 is it possible ?

You can you use either pnotes or subprocess_env (env variables).

-wjt

executing PerlHandler after default_handler?

[William T]

Does anyone if it's possible to fall through the default_handler
(decline?) to a PerlHandler?

What I want to do is issue a redirect if the file that was requested
is not on disk, and I don't want the extra stat due to an NFS mount.

Of course I can serve up the file myself, but it seems as though I
should be able to leverage the default_handler.

-wjt

Re: mod_perl configuration

[William A. Rowe, Jr.]

sandhya pawar wrote:
 mod_perl.so has been successfully installed to
 C:/PROGRA~1/APACHE~1/Apache2.2/modules.
 To enable mod_perl, put in the directives
LoadFile C:/Path/to/Perl/bin/perl510.dll
LoadModule perl_module modules/mod_perl.so
 in httpd.conf. For more information, visit
http://perl.apache.org/
 and especially see
http://perl.apache.org/docs/2.0/rename.html
 
 done

Including LoadFile prior to LoadModule?

 But it gives the error when I adds the following line in httpd.conf?
 
 LoadModule perl_module modules/mod_perl.so
 
 Error:
 The request operation has failed.

What does httpd -t say?  What does your error log say?  What does your
windows application event log say about httpd?

Re: Security Related BUG within ModPerl 2.0.4

[William A. Rowe, Jr.]

I would like to report a security related bug within ModPerl 2.0.4, 
though prefer not to disclose the details to  a public channel.


The appropriate secure channel for all ASF related security vulnerability
reporting is the closed list, secur...@apache.org, which will be triaged
to the appropriate committers or committee.

Re: unsubscribe

[William A. Rowe, Jr.]

André Warnier wrote:
 Phil Carmody wrote:
 --- On Fri, 1/23/09, David Nicol davidni...@gmail.com wrote:
 [...]
 I am personally against any change to the current situation.
 These misdirected unsubscribe messages always seem to provide a useful
 outlet for whomever needs to let out steam..
 :-)

Awww... put the footer on the messages.  Trust me, from us...@httpd
experience, you'll still have plenty of fun (more probably, if they
couldn't read to the bottom of the message they are ensured of seeing).

Re: Multiple mod_perl 2.0 installations on one Linux machine

[William A. Rowe, Jr.]

Torsten Foertsch wrote:
 On Mon 19 Jan 2009, Adam Prime wrote:
 I thought you could build more than one and load the one you want
 at runtime.  Isn't that what Red Hat does?
 If redhat's shipping more than one mpm, they've patched httpd.
 
 Probably not httpd. At least Suse has not. Instead they configure and 
 build a prefork httpd and a worker httpd one by one and then merge the 
 result. The apache API does not depend on the chosen MPM. So, almost 
 certainly you can build modules (including mod_perl) with one MPM and 
 use it with another.

Built with a threaded MPM and any module should also work on prefork etc.

But not visa-versa!!!

Re: which reverse proxy for modperl?

[William A. Rowe, Jr.]

Jeff Pang wrote:
 Hello,
 
 I have a modperl application on a host which is running with heavy load.
 I have the plan to put a reverse proxy before it.
 There are two well known reverse proxy software, one is Squid, another
 is nginx.
 Which one is better for modperl application? or is there any others
 which are better than these two?

And there is httpd which you are already running, and you can run a very
low cost, separate instance with very minimal modules loaded.  With the
mod_proxy_balancer, you can shuffle off some of the traffic to a second,
third machine for good measure.

Is either better?  Google both for problems to determine how many people
are irritated with either.

Error.pm and RegistryCooker

[William Ahern]

I was forced to move from mod_perl to mod_perl2 because of Ubuntu. I had
originally created an Apache-Cocoon/Apache-AxKit-type infrastructure for the
site. Pages just generated an XML tree and apply 1 or more XSLT stylesheets.
There were more issues than I could posibly count (mostly my fault, I'm
sure, though my code was able to core dump mod_perl2!) with how I was
manipulating mod_perl and Apache which arose on the transition.

Anyhow, unfortunately for me, I'm using Error.pm exceptions all over the
place. One way I use it is for redirection: throw E:Redirect url =
http://foo. And I'm wrapping the RegistryCooker handler (Registry handler in
mod_perl 1). I have a catch statement in my handler, though I guess I never
realized that my redirect trick was working by accident in mod_perl 1, and
now it doesn't work at all in mod_perl 2. (By accident because the
default_handler executes the page in an eval {})

The redirect exception object construction sets the Location header and
status code. With mod_perl 1 I guess this was enough to get the job done,
but with mod_perl 2 this just doesn't fly. (I Suppose now mod_perl 2 munges
the status code).

I guess what I'm asking is what's the quickest way to get the actual
behavior that I want; specifically, being able to throw exceptions into my
andler. Re-writing the default handler (which loads and caches the pages)
seems like the most work, so I'm looking for an easier answer, if any ;) For
that effort it seems I might was well grab Cocoon 3 and switch to Java.

- Bill

Re: mod_perl survey results

[William A. Rowe, Jr.]

Adam Prime wrote:
 André Warnier wrote:
 Maybe this is the time to ask.
 I am using Linux Debian, and getting Apache 2, perl and mod_perl 2
 from there (apt-get).
 I have never been quite sure which mpm the packager decided to
 configure, as the apache2.conf contains parameters for prefork,
 pthread and perchild. So,
 a) which is the best way to find out ?
 b) if it happened to be worker or something, could I just change
 that to prefork, or is there more to it ?

 (Also so far, even if it is using a threaded mpm, it does not seem to
 have any deleterious effect on my systems, which are pretty stable).

 Thanks
 ./httpd -V
 Server version: Apache/2.0.54
 Server built:   Sep 25 2005 00:31:31
 Server's Module Magic Number: 20020903:9
 Architecture:   32-bit
 Server compiled with
 -D APACHE_MPM_DIR=server/mpm/prefork
 ...
 
 The -D APACHE_MPM_DIR tells you which MPM your apache is using.  In
 order to change MPM's you need to recompile apache, and quite possibly
 mod_perl as well, i have no idea how you'd accomplish that on debian
 using apt.

Not probably... you need perl built for threading, and httpd built for
threading.

There is a very strong probability that httpd 2.4/3.0 will encourage no
prefork style servers, and by the following major rev, they will be
discarded altogether.  Already apr builds to support threads unless you
are very persistent in telling it no, thank you.

We will never attain async servers/more-requests-than-children until we
wholly embrace threading, and free-threading at that :)

But your poll doesn't surprise me, Covalent's shipped a threaded perl,
both MPM's for now some 6+ years, and the customers have appreciated it
significantly.

The fact that the PHP project can't persuade people to upgrade 10 year old
non-reentrant libraries doesn't change the fact that several linux vendors
now ship a worker model by default.  I'd hope the modperl crew doesn't
follow their nonsensical flip mid-minor-version to make the zts support
experimental/maintainer - that was lame :)

It's better to plow through these issues, and then decide based on real
pragmatism and cpu load if prefork or worker is better suited, and then
prepare to embrace the next decade of free threaded applications.

Re: mod_perl survey results

[William A. Rowe, Jr.]

Foo JH wrote:
 Adam Prime wrote:
 The results of the mod_perl survey that Fred Moyer and I conducted can
 be found at the following link:
 Interesting list. Any chance the workshop will come to Singapore? :)

Not quite, but close...

http://us.apachecon.com/c/accn2008/

(when this link breaks, substitute cn. for us. --- but dns hasn't caught
up).

Would be cool to have some mod_perl fandom in the house!

Re: Windows settings cause crash (originally: FAIL!!!)

[William A. Rowe, Jr.]

Before changing either detail that Foo JH pointed out, first try backing
down to activestate perl 5.8 build 820(?).  It seemed to be a very stable build
for most people's use.

Foo JH wrote:
 You may want to try 2 options:
 1. Use an older version of the Apache build like 2.2.6. It has been
 known to be fairly stable.
 2. Try the build from ApacheLounge. It's generally not favoured, but it
 seems to handle some things better.
 
 greg augustine wrote:
 Also, the ThreadsPerChild is 250 and MaxRequestsPerChild  5

   From: [EMAIL PROTECTED]
   To: modperl@perl.apache.org
   Subject: FAIL!!!
   Date: Mon, 13 Oct 2008 07:47:35 -0500
  
  
   hello,
  
   I'm trying to get mod_perl running under Windows. I used the latest
 perl from ActiveState (5.8.8.824), Apache 2.2.9 from apache.org, and
 mod_perl 2.0.4, installed from ppm. When I ran a simple perl script
 and had 20 simulated users hitting the page, it eventually said 'Out
 of memory!' and restarted with a status of 0. The second time it
 happened, it tried to restart, but couldn't. Does anyone know if these
 versions actually work together? If they do, any thoughts on what
 could be wrong?
  
   code:
  
   use strict;
  
  
   my $err = 'eh';
  
   my $body;
  
   my $errstr = int(rand(2));
  
   print 'Content-type: text/html','\n\n',$err,':
 ',$errstr,'\nSERVER_ADDR: ',($ENV{'SERVER_ADDR'} ||
 $ENV{'COMPUTERNAME'}),'\n';
   if($errstr){
   $errstr =~ s/\://g;
   $errstr =~ s/\n/ /g;
   $body = 'Error Text: ',$errstr,'\n';
   }
   print '\n';
   print scalar(localtime());
   if($body){ $body =~ s/\n//g; }
   print $body;
  
  
   Apache error.log
  
   Out of memory!
   [Fri Oct 10 14:25:34 2008] [notice] Parent: child process exited
 with status 0 -- Restarting.
   [Fri Oct 10 14:25:34 2008] [notice] Apache/2.2.9 (Win32)
 mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations
   [Fri Oct 10 14:25:34 2008] [notice] Server built: Jun 13 2008 04:04:59
   [Fri Oct 10 14:25:34 2008] [notice] Parent: Created child process 1712
   [Fri Oct 10 14:25:34 2008] [debug] mpm_winnt.c(487): Parent: Sent
 the scoreboard to the child
   [Fri Oct 10 14:25:34 2008] [notice] Disabled use of AcceptEx()
 WinSock2 API
   [Fri Oct 10 14:25:34 2008] [notice] Child 1712: Child process is
 running
   [Fri Oct 10 14:25:34 2008] [info] Parent: Duplicating socket 244
 and sending it to child process 1712
   [Fri Oct 10 14:25:34 2008] [debug] mpm_winnt.c(408): Child 1712:
 Retrieved our scoreboard from the parent.
   [Fri Oct 10 14:25:34 2008] [debug] mpm_winnt.c(605): Parent: Sent 1
 listeners to child 1712
   [Fri Oct 10 14:25:34 2008] [debug] mpm_winnt.c(564): Child 1712:
 retrieved 1 listeners from parent
   [Fri Oct 10 14:25:34 2008] [notice] Child 1712: Acquired the start
 mutex.
   [Fri Oct 10 14:25:34 2008] [notice] Child 1712: Starting 250 worker
 threads.
   [Fri Oct 10 14:25:34 2008] [notice] Child 1712: Listening on port 80.
   Out of memory!
   [Fri Oct 10 15:07:14 2008] [notice] Parent: child process exited
 with status 0 -- Restarting.
  
   _
   See how Windows connects the people, information, and fun that are
 part of your life.
   http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/

 
 Get more out of the Web. Learn 10 hidden secrets of Windows Live.
 Learn Now
 http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_getmore_092008

 
 
 

Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat

[William A. Rowe, Jr.]

Fred Moyer wrote:

William A. Rowe, Jr. wrote:

Bianca Taylor wrote:
/bin/ld: 
/tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoader.o): 
relocation R_X86_64_32 against `a local symbol' can not be used when 
making a shared object; recompile with -fPIC
/tmp/unisolve/perl/lib/5.8.8/x86_64-linux/auto/DynaLoader/DynaLoader.a: 
could not read symbols: Bad value

collect2: ld returned 1 exit status
make[1]: *** [mod_perl.so] Error 1
make[1]: Leaving directory 
`/home/unisolve/mod_perl-2.0.4/src/modules/perl'

make: *** [modperl_lib] Error 2


Perl itself makes several bad calls w.r.t. CFLAGS, LDFLAGS, SHLDFLAGS 
etc,

that are propagated also into config_heavy.pl.  On several platforms I've
noted that -fPIC is ignored, on others I've noted that specific flag 
values

are dropped for the building of shared libs.

It's a matter of working backwards from modperl's build into the config
script of perl to determine where perl went wrong.



The solution should be as easy as recompiling perl with -fPIC.  Here's a 
link to the list archives where this has been discussed in detail.


http://www.gossamer-threads.com/lists/engine?list=modperl;do=search_results;search_forum=forum_8;search_string=fpic;search_type=ANDsb=post_time 


Of course, that's what it says above.  My point is, I've had perl yank -fPIC
from my demands on the build on PPC arch.  Mighty kind of it, eh?

Re: DynaLoader.a: could not read symbols: Bad value - Can't build on vanilla Red Hat

[William A. Rowe, Jr.]

Bianca Taylor wrote:


So at this point, I am confident that I compile Perl with -fPIC. I read all
the ducumentation you pointed me to and that I could find, but it keeps
coming back to the same error.


You aren't... please review your shared cc flags from perl.  The flag you
looked at was not a shlib cflag, but a program cflag.

Re: mod_perl caching problem

[william]

Hello, Sorry for the late of reply, I just solve it yesterday. It's
because a module of mine is using the global variable
our @array = ();

When I migrate from CGI to mod_perl, I forgot to fix that. Now I just
understand that because mod_perl only compile once, and the subsequent
execution of global variables are remembered. So I solved it by
reseting that global variable before that global variable is used.


Thanks.

On 6/27/08, Perrin Harkins [EMAIL PROTECTED] wrote:
 On Tue, Jun 24, 2008 at 9:07 AM, william [EMAIL PROTECTED] wrote:
   Before asking here, I had read a few articles in perl.apache.org about
   caching issue in mod_perl, but I still don't get it right with my
   program when I had already changed the input, it still giving me the
   result of old input.


 Are you still having trouble with this, or did you fix the problem?


  - Perrin

mod_perl caching problem

[william]

Hello,

Before asking here, I had read a few articles in perl.apache.org about
caching issue in mod_perl, but I still don't get it right with my
program when I had already changed the input, it still giving me the
result of old input. I aware that the child process will only compile
the code for once, but I had also read somewhere that it will
recompile when it found that the file has been changed. What I want to
achieve is the program should give me the result according to the
input at that time.

#this is the main entrance of my program
use CGI qw(:standard);
print header;

use Qwerq::Core;
our $qwerq = new Qwerq::Core();
$qwerq-query(what is the population of China);

How can I solve this problem ?

Thanks.

Re: mod_perl caching problem

[william]

I like to add on something, I had put the pragma
use strict;
use warnings;

on all modules that I had, but I didn't get the warnings of Variable
$foo will not stay shared at... .

What other possibility that might cause my program to cache the result
even when the input has already changed ?

Thanks.

Re: mod_perl caching problem

[william]

Thank you for the reply,

That's one of the articles that I had read, but still I have not found
where my code having the my scoped variable in nested subroutines ,
I also aware of the nature of ModPerl::Registry would handle the code
in its subrountine called handle. I have used global variable our
for the variables that might caused problem.

On 6/24/08, Geoffrey Young [EMAIL PROTECTED] wrote:


  william wrote:

  I like to add on something, I had put the pragma
  use strict;
  use warnings;
 
  on all modules that I had, but I didn't get the warnings of Variable
  $foo will not stay shared at... .
 
  What other possibility that might cause my program to cache the result
  even when the input has already changed ?
 
 

 http://perl.apache.org/docs/general/perl_reference/perl_reference.html#myScoped_Variable_in_Nested_Subroutines

  --Geoff

Fwd: mod_perl interactive debugging

[william]

-- Forwarded message --
From: william [EMAIL PROTECTED]
Date: Jun 1, 2008 6:11 PM
Subject: Re: mod_perl interactive debugging
To: Fred Moyer [EMAIL PROTECTED]


On 6/1/08, william [EMAIL PROTECTED] wrote:
  On 6/1/08, william [EMAIL PROTECTED] wrote:
On 6/1/08, Fred Moyer [EMAIL PROTECTED] wrote:
  william wrote:
 
   On 5/29/08, william [EMAIL PROTECTED] wrote:
  
On 5/29/08, Fred Moyer [EMAIL PROTECTED] wrote:
  william wrote:
 
   On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
  
On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED]
  wrote:
   
   I put the following lines at the top of my startup.pl script
   use APR::Pool (); #specific for mod_perl 2
   use Apache::DB ();
   Apache::DB-init();
  
 
   Can you show us the part of httpd.conf where you call
startup.pl?
 
   I always place my debugger calls before any other modules load,
  usually
  right after mod_perl.so is loaded.
   
   
Thanks for the prompt reply, here it is.
   
 /etc/apache2/httpd.conf
   
 Directory /var/www/cgi-bin
  Options +ExecCGI
  AddHandler cgi-script cgi pl
 /Directory
   
 ServerName localhost
   
   
 # Alias /modperl/ /var/www/modperl/
   
 # IfDefine PERLDB
 # Perl
 #  use APR::Pool ();
 #   use Apache::DB ();
 #   Apache::DB-init;
   
 #   warn PERLDB executed;
 # /Perl
 # Location /modperl/
 #   PerlFixupHandler Apache::DB
 # /Location
 # /IfDefine
   
   
 #The startup script
 PerlRequire '/var/www/modperl/Apache2/startup.pl'
   
   
  
 
   I didn't see a LodModule directive in there anywhere - do
you have a line
  like 'LoadModule perl_module modules/mod_perl.so'?
 
   It looked like you were using mod_perl2, so it is very
likely that you have
  that line in there somewhere (I don't know of anyone who has
done a static
  build with mp2.
 
 
   hello, I am still looking for solution. When command
   sudo apache2 -X  -k restart
   The debugger would immediately startup at this shell ?
  
 
   The debugger will start once the first request to the server is made.
 
 
   
   
My apache configuration file is not just at the httpd.conf , I also
 have the apache2.conf
   
 I have this line in /etc/apache2/mods-enabled/perl.load
 LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so
   
 Yes, I am using
 mod_perl/2.0.4
 Perl/v5.10.0
   
 I am able to run my perl script under mod_perl, without any problem.
   
   
  The debugger will start once the first request to the server is made.
   
   
So the debugger would appear in which shell ?
   
 I only get to see the debugging process in /var/log/apache2/error.log
 , but not able to have interactive debugging feature.
   
 Thanks.
   
   
 apache2.conf
 #
 # Based upon the NCSA server configuration files originally by
Rob McCool.
 #
 # This is the main Apache server configuration file.  It contains the
 # configuration directives that give the server its instructions.
 # See http://httpd.apache.org/docs/2.2/ for detailed information about
 # the directives.
 #
 # Do NOT simply read the instructions in here without understanding
 # what they do.  They're here only as hints or reminders.  If
you are unsure
 # consult the online docs. You have been warned.
 #
 # The configuration directives are grouped into three basic sections:
 #  1. Directives that control the operation of the Apache
server process as a
 # whole (the 'global environment').
 #  2. Directives that define the parameters of the 'main' or
'default' server,
 # which responds to requests that aren't handled by a virtual host.
 # These directives also provide default values for the settings
 # of all virtual hosts.
 #  3. Settings for virtual hosts, which allow Web requests to be sent to
 # different IP addresses or hostnames and have them handled by the
 # same Apache server process.
 #
 # Configuration and logfile names: If the filenames you specify for many
 # of the server's control files begin with / (or drive:/
for Win32), the
 # server will use that explicit path.  If the filenames do *not* begin
 # with /, the value of ServerRoot is prepended -- so
 /var/log/apache2/foo.log
 # with ServerRoot set to  will be interpreted by the
 # server as //var/log/apache2/foo.log.
 #
   
 ### Section 1: Global Environment
 #
 # The directives in this section affect the overall

Re: mod_perl interactive debugging

[william]

On 5/29/08, william [EMAIL PROTECTED] wrote:
 On 5/29/08, Fred Moyer [EMAIL PROTECTED] wrote:
   william wrote:
  
On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
   
 On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED] wrote:

I put the following lines at the top of my startup.pl script
use APR::Pool (); #specific for mod_perl 2
use Apache::DB ();
Apache::DB-init();
   
  
Can you show us the part of httpd.conf where you call startup.pl?
  
I always place my debugger calls before any other modules load, usually
   right after mod_perl.so is loaded.


 Thanks for the prompt reply, here it is.

  /etc/apache2/httpd.conf

  Directory /var/www/cgi-bin
Options +ExecCGI
AddHandler cgi-script cgi pl
  /Directory

  ServerName localhost


  # Alias /modperl/ /var/www/modperl/

  # IfDefine PERLDB
  # Perl
  #  use APR::Pool ();
  #   use Apache::DB ();
  #   Apache::DB-init;

  #   warn PERLDB executed;
  # /Perl
  # Location /modperl/
  #   PerlFixupHandler Apache::DB
  # /Location
  # /IfDefine


  #The startup script
  PerlRequire '/var/www/modperl/Apache2/startup.pl'


  
 --



  /etc/apache2/sites-enabled/000-default

  NameVirtualHost *
  VirtualHost *
 ServerAdmin [EMAIL PROTECTED]
 ServerName localhost
 DocumentRoot /var/www/


 Directory /var/www/
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 /Directory

  Alias /modperl/ /var/www/modperl/


  PerlModule ModPerl::RegistryPrefork
  Location /modperl/
   PerlFixupHandler Apache::DB
   SetHandler perl-script
   PerlResponseHandler ModPerl::RegistryPrefork
   PerlOptions +ParseHeaders
   Options +ExecCGI
   Order allow,deny
   Allow from all
  /Location


 ErrorLog /var/log/apache2/error.log

 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel warn

 CustomLog /var/log/apache2/access.log combined
 ServerSignature On

 Alias /doc/ /usr/share/doc/
 Directory /usr/share/doc/
 Options Indexes MultiViews FollowSymLinks
 AllowOverride None
 Order deny,allow
 Deny from all
 Allow from 127.0.0.0/255.0.0.0 ::1/128
 /Directory

  /VirtualHost

  /VirtualHost



hello, I am still looking for solution. When command
sudo apache2 -X  -k restart
The debugger would immediately startup at this shell ?

Thanks

Re: mod_perl interactive debugging

[william]

On 6/1/08, Fred Moyer [EMAIL PROTECTED] wrote:
 william wrote:

  On 5/29/08, william [EMAIL PROTECTED] wrote:
 
   On 5/29/08, Fred Moyer [EMAIL PROTECTED] wrote:
 william wrote:

  On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
 
   On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED]
 wrote:
  
  I put the following lines at the top of my startup.pl script
  use APR::Pool (); #specific for mod_perl 2
  use Apache::DB ();
  Apache::DB-init();
 

  Can you show us the part of httpd.conf where you call startup.pl?

  I always place my debugger calls before any other modules load,
 usually
 right after mod_perl.so is loaded.
  
  
   Thanks for the prompt reply, here it is.
  
/etc/apache2/httpd.conf
  
Directory /var/www/cgi-bin
 Options +ExecCGI
 AddHandler cgi-script cgi pl
/Directory
  
ServerName localhost
  
  
# Alias /modperl/ /var/www/modperl/
  
# IfDefine PERLDB
# Perl
#  use APR::Pool ();
#   use Apache::DB ();
#   Apache::DB-init;
  
#   warn PERLDB executed;
# /Perl
# Location /modperl/
#   PerlFixupHandler Apache::DB
# /Location
# /IfDefine
  
  
#The startup script
PerlRequire '/var/www/modperl/Apache2/startup.pl'
  
  
 

  I didn't see a LodModule directive in there anywhere - do you have a line
 like 'LoadModule perl_module modules/mod_perl.so'?

  It looked like you were using mod_perl2, so it is very likely that you have
 that line in there somewhere (I don't know of anyone who has done a static
 build with mp2.


  hello, I am still looking for solution. When command
  sudo apache2 -X  -k restart
  The debugger would immediately startup at this shell ?
 

  The debugger will start once the first request to the server is made.



My apache configuration file is not just at the httpd.conf , I also
have the apache2.conf

I have this line in /etc/apache2/mods-enabled/perl.load
LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so

Yes, I am using
mod_perl/2.0.4
Perl/v5.10.0

I am able to run my perl script under mod_perl, without any problem.

 The debugger will start once the first request to the server is made.

So the debugger would appear in which shell ?

I only get to see the debugging process in /var/log/apache2/error.log
, but not able to have interactive debugging feature.

Thanks.


apache2.conf
#
# Based upon the NCSA server configuration files originally by Rob McCool.
#
# This is the main Apache server configuration file.  It contains the
# configuration directives that give the server its instructions.
# See http://httpd.apache.org/docs/2.2/ for detailed information about
# the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do.  They're here only as hints or reminders.  If you are unsure
# consult the online docs. You have been warned.
#
# The configuration directives are grouped into three basic sections:
#  1. Directives that control the operation of the Apache server process as a
# whole (the 'global environment').
#  2. Directives that define the parameters of the 'main' or 'default' server,
# which responds to requests that aren't handled by a virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
#  3. Settings for virtual hosts, which allow Web requests to be sent to
# different IP addresses or hostnames and have them handled by the
# same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with / (or drive:/ for Win32), the
# server will use that explicit path.  If the filenames do *not* begin
# with /, the value of ServerRoot is prepended -- so
/var/log/apache2/foo.log
# with ServerRoot set to  will be interpreted by the
# server as //var/log/apache2/foo.log.
#

### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE!  If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation (available
# at URL:http://httpd.apache.org/docs-2.1/mod/mpm_common.html#lockfile);
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
#
ServerRoot /etc/apache2

#
# The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
#
#IfModule !mpm_winnt.c
#IfModule !mpm_netware.c
LockFile /var/lock/apache2/accept.lock
#/IfModule
#/IfModule

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
# This needs to be set in /etc/apache2

Re: mod_perl interactive debugging

[william]

On 6/1/08, william [EMAIL PROTECTED] wrote:
 On 6/1/08, Fred Moyer [EMAIL PROTECTED] wrote:
   william wrote:
  
On 5/29/08, william [EMAIL PROTECTED] wrote:
   
 On 5/29/08, Fred Moyer [EMAIL PROTECTED] wrote:
   william wrote:
  
On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
   
 On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED]
   wrote:

I put the following lines at the top of my startup.pl script
use APR::Pool (); #specific for mod_perl 2
use Apache::DB ();
Apache::DB-init();
   
  
Can you show us the part of httpd.conf where you call startup.pl?
  
I always place my debugger calls before any other modules load,
   usually
   right after mod_perl.so is loaded.


 Thanks for the prompt reply, here it is.

  /etc/apache2/httpd.conf

  Directory /var/www/cgi-bin
   Options +ExecCGI
   AddHandler cgi-script cgi pl
  /Directory

  ServerName localhost


  # Alias /modperl/ /var/www/modperl/

  # IfDefine PERLDB
  # Perl
  #  use APR::Pool ();
  #   use Apache::DB ();
  #   Apache::DB-init;

  #   warn PERLDB executed;
  # /Perl
  # Location /modperl/
  #   PerlFixupHandler Apache::DB
  # /Location
  # /IfDefine


  #The startup script
  PerlRequire '/var/www/modperl/Apache2/startup.pl'


   
  
I didn't see a LodModule directive in there anywhere - do you have a line
   like 'LoadModule perl_module modules/mod_perl.so'?
  
It looked like you were using mod_perl2, so it is very likely that you 
 have
   that line in there somewhere (I don't know of anyone who has done a static
   build with mp2.
  
  
hello, I am still looking for solution. When command
sudo apache2 -X  -k restart
The debugger would immediately startup at this shell ?
   
  
The debugger will start once the first request to the server is made.
  
  


 My apache configuration file is not just at the httpd.conf , I also
  have the apache2.conf

  I have this line in /etc/apache2/mods-enabled/perl.load
  LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so

  Yes, I am using
  mod_perl/2.0.4
  Perl/v5.10.0

  I am able to run my perl script under mod_perl, without any problem.


   The debugger will start once the first request to the server is made.


 So the debugger would appear in which shell ?

  I only get to see the debugging process in /var/log/apache2/error.log
  , but not able to have interactive debugging feature.

  Thanks.


  apache2.conf
  #
  # Based upon the NCSA server configuration files originally by Rob McCool.
  #
  # This is the main Apache server configuration file.  It contains the
  # configuration directives that give the server its instructions.
  # See http://httpd.apache.org/docs/2.2/ for detailed information about
  # the directives.
  #
  # Do NOT simply read the instructions in here without understanding
  # what they do.  They're here only as hints or reminders.  If you are unsure
  # consult the online docs. You have been warned.
  #
  # The configuration directives are grouped into three basic sections:
  #  1. Directives that control the operation of the Apache server process as a
  # whole (the 'global environment').
  #  2. Directives that define the parameters of the 'main' or 'default' 
 server,
  # which responds to requests that aren't handled by a virtual host.
  # These directives also provide default values for the settings
  # of all virtual hosts.
  #  3. Settings for virtual hosts, which allow Web requests to be sent to
  # different IP addresses or hostnames and have them handled by the
  # same Apache server process.
  #
  # Configuration and logfile names: If the filenames you specify for many
  # of the server's control files begin with / (or drive:/ for Win32), the
  # server will use that explicit path.  If the filenames do *not* begin
  # with /, the value of ServerRoot is prepended -- so
  /var/log/apache2/foo.log
  # with ServerRoot set to  will be interpreted by the
  # server as //var/log/apache2/foo.log.
  #

  ### Section 1: Global Environment
  #
  # The directives in this section affect the overall operation of Apache,
  # such as the number of concurrent requests it can handle or where it
  # can find its configuration files.
  #

  #
  # ServerRoot: The top of the directory tree under which the server's
  # configuration, error, and log files are kept.
  #
  # NOTE!  If you intend to place this on an NFS (or otherwise network)
  # mounted filesystem then please read the LockFile documentation (available
  # at URL:http://httpd.apache.org/docs-2.1/mod/mpm_common.html#lockfile);
  # you will save yourself a lot of trouble.
  #
  # Do NOT add a slash at the end of the directory path.
  #
  ServerRoot /etc/apache2

Syntax error in mod_perl but not in shell command

[william]

Hello, I am running this code

print Content-type: text/html\n\n;

use Switch;
$t =1;

switch ($t) {
case 1  { print number 1\n; }
}

I have not problem running in shell command
[EMAIL PROTECTED]:/var/www/modperl$ perl test.pl
Content-type: text/html

number 1

But when I ran in mod_perl , I got error
[Thu May 29 14:48:16 2008] [error] syntax error at
/var/www/modperl/test.pl line 6, near ) {\nNumber found where
operator expected at /var/www/modperl/test.pl line 7, near case
1\nsyntax error at /var/www/modperl/test.pl line 8, near }\n}\n


Thanks

Re: Syntax error in mod_perl but not in shell command

[william]

On 5/30/08, Heiko Jansen [EMAIL PROTECTED] wrote:
 As far as I understand it, mod_perl will eval{} the code it's going to
  run and in the paragraph Limitations on
  http://search.cpan.org/~rgarcia/Switch-2.13/Switch.pm
  we're told that Due to the way source filters work in Perl, you can't
  use Switch inside an string eval..


  heiko




Yeah, I love mod_perl but it's a little disappointing, because I guess
I would not longer assume that whatever that I can run in CGI, I can
run in mod_perl too. I have upgraded my perl to 5.10 now. Thanks.

Re: mod_perl interactive debugging

[william]

On Wed, May 28, 2008 at 5:50 AM, Perrin Harkins [EMAIL PROTECTED] wrote:
 On Tue, May 27, 2008 at 1:38 PM, william [EMAIL PROTECTED] wrote:
 Hello, I am trying to debug my perl code under mod_perl and I had
 followed all the instruction at this section
 http://perl.apache.org/docs/1.0/guide/debug.html#Interactive_mod_perl_Debugging

 I managed to see my perl debugging console prompted , but this prompt
 is shown by the
 tail -f /var/log/apache2.log

 Did you actually start your server with httpd -X as shown in that 
 documentation?

 - Perrin


Thanks for the reply, yes I did,
[EMAIL PROTECTED]:~$ sudo apache2 -X -DPERLDB -k restart
[notice] Apache::DB initialized in child 10312

Do I have to use DDD to see the prompt ? Where would the debugger
prompt appear when I use the browser to request the file ? Thanks

Re: mod_perl interactive debugging

[william]

On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
 On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED] wrote:
   [EMAIL PROTECTED]:~$ sudo apache2 -X -DPERLDB -k restart
   [notice] Apache::DB initialized in child 10312
  
   Do I have to use DDD to see the prompt ?


 No, it should just be right there in your terminal.  It seems to be
  forking.  Are you sure apache2 is the httpd executable and not some
  script?  By the way, if you want a reference that's written for using
  the debugger with mod_perl 2, try this one:
  http://www.perl.com/pub/a/2006/02/09/debug_mod_perl.html


  - Perrin



Thanks for the link, I have just read that. It's still almost the same.

PerlModule ModPerl::RegistryPrefork
Location /modperl/
PerlFixupHandler Apache::DB

SetHandler perl-script
PerlResponseHandler ModPerl::RegistryPrefork
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Order allow,deny
  Allow from all
/Location

If I am using  ModPerl::RegistryPrefork instead of  ModPerl::Registry
would it matter ?


I put the following lines at the top of my startup.pl script
use APR::Pool (); #specific for mod_perl 2
use Apache::DB ();
Apache::DB-init();

When I put the immediate-above code in Perl/Perl it's does
executed but my /var/log/apach2/errror.log does not show the debugging
process, so when I put in startup.pl script then only I will see the
debugging process

 DB1 
ModPerl::RegistryCooker::error_check(/usr/local/lib/perl/5.8.8/ModPerl/RegistryCooker.pm:698):
698:return Apache2::Const::SERVER_ERROR;
  DB1 
ModPerl::RegistryCooker::convert_script_to_compiled_handler(/usr/local/lib/perl/5.8.8/ModPerl/RegistryCooker.pm:407):
407:return $rc unless $rc == Apache2::Const::OK;
  DB1 
ModPerl::RegistryCooker::default_handler(/usr/local/lib/perl/5.8.8/ModPerl/RegistryCooker.pm:164):
164:return $rc unless $rc == Apache2::Const::OK;
  DB1 [Thu May 29 13:09:08 2008] [error] [client 127.0.0.1] File
does not exist: /var/www/favicon.ico, referer:
http://localhost/modperl/main.pl


 Are you sure apache2 is the httpd executable and not some
script?

How do I check that ?


Now it's weird, when I check the error.log , many lines of code are
executed repeatedly, does that shows that I am not really using single
process ? Here are a few of it. Thanks.

82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);
  DB1 WordNet::Tools::new(/usr/local/share/perl/5.8.8/WordNet/Tools.pm:82):
82:   $self-{compounds}-{$word} = 1 if ($word =~ /_/);



  DB1 File::Temp::CODE(0xabf9548)(/usr/share/perl/5.8/File/Temp.pm:132):
132:use 5.005;
  DB1 File::Temp::CODE(0xabf9548)(/usr/share/perl/5.8/File/Temp.pm:132):
132:use 5.005;
  DB1 File::Temp::CODE(0xabf9548)(/usr/share/perl/5.8/File/Temp.pm:132):
132:use 5.005;
  DB1 File::Temp::CODE(0xabf9554)(/usr/share/perl/5.8/File/Temp.pm:133):
133:use strict;
  DB1 File::Temp::CODE(0xabf9554)(/usr/share/perl/5.8/File/Temp.pm:133):
133:use strict;
  DB1 File::Temp::CODE(0xabf9554)(/usr/share/perl/5.8/File/Temp.pm:133):
133:use strict;
  DB1 File::Temp::CODE(0xabf9560)(/usr/share/perl/5.8/File/Temp.pm:134):
134:use Carp;
  DB1 File::Temp::CODE(0xabf9560)(/usr/share/perl/5.8/File/Temp.pm:134):
134:use Carp;
  DB1 File::Temp::CODE(0xabf9560)(/usr/share/perl/5.8/File/Temp.pm:134):
134:use Carp;

Re: mod_perl interactive debugging

[william]

On 5/29/08, Fred Moyer [EMAIL PROTECTED] wrote:
 william wrote:

  On 5/29/08, Perrin Harkins [EMAIL PROTECTED] wrote:
 
   On Wed, May 28, 2008 at 3:33 AM, william [EMAIL PROTECTED] wrote:
  
  I put the following lines at the top of my startup.pl script
  use APR::Pool (); #specific for mod_perl 2
  use Apache::DB ();
  Apache::DB-init();
 

  Can you show us the part of httpd.conf where you call startup.pl?

  I always place my debugger calls before any other modules load, usually
 right after mod_perl.so is loaded.

Thanks for the prompt reply, here it is.

/etc/apache2/httpd.conf

Directory /var/www/cgi-bin
   Options +ExecCGI
   AddHandler cgi-script cgi pl
/Directory

ServerName localhost


# Alias /modperl/ /var/www/modperl/

# IfDefine PERLDB
# Perl
#  use APR::Pool ();
#   use Apache::DB ();
#   Apache::DB-init;   

#   warn PERLDB executed;
# /Perl
# Location /modperl/
#   PerlFixupHandler Apache::DB
# /Location
# /IfDefine


#The startup script
PerlRequire '/var/www/modperl/Apache2/startup.pl'


--



/etc/apache2/sites-enabled/000-default

NameVirtualHost *
VirtualHost *
ServerAdmin [EMAIL PROTECTED]
ServerName localhost
DocumentRoot /var/www/


Directory /var/www/
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
/Directory

Alias /modperl/ /var/www/modperl/

PerlModule ModPerl::RegistryPrefork
Location /modperl/
  PerlFixupHandler Apache::DB
  SetHandler perl-script
  PerlResponseHandler ModPerl::RegistryPrefork
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Order allow,deny
  Allow from all
/Location

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined
ServerSignature On

Alias /doc/ /usr/share/doc/
Directory /usr/share/doc/
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
/Directory

/VirtualHost

/VirtualHost