Re: [mp2] Re: Getting help for MasonX::Apache2Handler
<...> >> > >> > The 'perl Makefile.PL' statement ran properly without errors on Linux >> > 2.6.3 but on Darwin 7.0.3 building the Makefile generated the >> following >> > error. This occurs with the latest releases as well as cvs tips of >> > apreq2 and mp2. Perl 5.8.3 and httpd-2.0.49 were used. >> > >> > Checking if your kit is complete... >> > Looks good >> > dyld: perl Undefined symbols: >> > /Users/fredmoyer/dev/perl-5.8.3/lib/site_perl/5.8.3/darwin-2level/auto/ >> > APR/Table/Table.bundle undefined reference to _modperl_hash_tie >> > expected to be defined in a dynamic image >> > /Users/fredmoyer/dev/perl-5.8.3/lib/site_perl/5.8.3/darwin-2level/auto/ >> > APR/Table/Table.bundle undefined reference to >> _modperl_hash_tied_object >> > expected to be defined in a dynamic image >> > Trace/BPT trap >> >> It shouldn't try to load APR::Table unless mod_perl is loaded and >> running. >> Where is it getting loaded from? > > Hi Stas and Fred - > > I am befuddled. Fred says this happended 'building the make file' > which I take to mean running Makefile.PL (is that what you mean Fred?) > The 'Makefile.PL' is pretty standard: > > use 5.008; > use ExtUtils::MakeMaker; use Apache2 (); I added use 'Apache2();' right here. But when I ran a new mod_perl2 configuration without MP_INST_APACHE2 the same error above occurred (without use Apache2 pragma). So I think the initial problem of 'use Apache2 ();' was solved and this was next in line. I'll try this from fresh checkouts to make sure nothing went awry. I had to make some compatibility changes to apreq2 for darwin with regards to glibtool but other than that no changes to the code. It's working great on Linux ;) -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hmmmm....
> I am wondering why it's trying to run the file Rules2.pm. Why doesn't it > just restart then wait to report the error when I attempt to access > scinux.redwoods/mod_perl_rules2? Mod_Perl compiles all library modules and loads them into memory when the Apache server is started. That is why mod_perl applications are so much faster than CGI applications, which compile at runtime. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
internal redirect in mod_perl 2 causes runaway process [mp2]
Greetings,
I encountered a runaway httpd process from the following code:
$r->internal_redirect('/my/url');
I'm using perl 5.8.4, apache 2.0.49, and the latest snapshots of mp2 and
httpd-apreq2. External redirects work fine. Is this a known bug, or a
possible problem with my implementation? How should I go about debugging
this?
Thanks,
Fred
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: HTTP headers - what is wrong
> Which works great, the problem is right before I print out any HTML, I > changed > > $CGI->header > to $r->send_http_header; The method $r->send_http_header() no longer exists in mod_perl 2.0. See the following link http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version > Apache/2.0.44 (Unix) mod_perl/1.99_08 Perl/v5.8.0 That version of mod_perl2 is quite old - the current version is 1.99_14. I recommend installing 1.99_14, much has changed and many bugs have been fixed. Regards, Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Bug & Patch: Segfault with PerlOptions -Enable
> -8<-- Start Bug Report 8<-- > 1. Problem Description: > >Apache2 segfaults when a virtual host is configured with >PerlOptions -Enable (using the libapache2-mod-perl2 package on a >stock Ubuntu 7.04 installation). > >A test case using bug-reporting-skeleton-mp2.tar.gz is available at >http://www.ece.ubc.ca/~derekp/webdevel/mp2-perloptions-enable-bug.tar.gz > >A patch to fix the segfault is included below. While it does fix the >segfault, it is not thoroughly tested. > > 2. Used Components and their Configuration: > > *** mod_perl version 2.02 Can you verify that this problem exists in 2.03 also (and svn trunk)? I checked the Changes for trunk and didn't see anything but if this problem still exists and your test case fixes it then there's a good chance we can add this fix once it's been verified.
[mp2] make fails under mp1.99_11, perl 5.8.2 src, httpd-2.0.48, rhat 2.4.20-20.9
Building mod_perl-1.99_11 under redhat 2.4.20-20.9, perl 5.8.2, and httpd-2.0.48 resulted in the following error: APR.xs:41:24: macro "extra_apr_init" passed 1 arguments, but takes just 0 APR.xs: In function `boot_APR': APR.xs:41: `extra_apr_init' undeclared (first use in this function) APR.xs:41: (Each undeclared identifier is reported only once APR.xs:41: for each function it appears in.) make[3]: *** [APR.o] Error 1 make[3]: Leaving directory `/home/httpd/httpd_perl/mod_perl-1.99_11/xs/APR/APR' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/httpd/httpd_perl/mod_perl-1.99_11/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/httpd/httpd_perl/mod_perl-1.99_11/xs' make: *** [subdirs] Error 2 Application of the following patch to xs/APR/APR/APR.xs corrected the problem and the build completed successfully: 31c31 < # define extra_apr_init() --- > # define extra_apr_init(aTHX) Regards, Fred -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: introducing new code with no perceived user delays?
On Thu, 2003-12-18 at 04:15, Stas Bekman wrote:
> Rob Nagler wrote:
> > Brian Hirt writes:
> >
> >>Once everything is running on the
> >>new mod perl, i shut down the original mod perl application. There is
> >>about 0.5 seconds of lag while the proxy reloads the rules.
> >
> >
> > We use proxies, but instead of modifying the proxy config, we use a
> > Rewrite rule of the form:
> >
> > RewriteMap maps txt:/etc/httpd.maps
> > RewriteRule ^(.*) http://${maps:appserver}$1 [proxy]
> >
> > When we release, we edit the /etc/httpd.maps file to point to a
> > different port or machine.
> >
> > appserver foo.com:
> >
> > mod_rewrite rereads (or checks mtime of) the file on every request so
> > the change takes effect immediately.
>
> That sounds like something that we want to have in the mod_perl documentation.
> Would someone come up with a doc patch? I think the perfect place for this
> would be: http://perl.apache.org/docs/1.0/guide/scenario.html
I had some free time last night so I wrote up a patch to
http://perl.apache.org/docs/1.0/guide/scenario.pod.orig. It includes
some of these list threads and splits up the examples so they are a bit
clearer to someone reading it for the first time. Hope this can be
useful.
1657,1659d1655
< Example code for using mod_rewrite with mod_perl application servers.
Several examples were taken from the mailing list.
<
< =head2 Rewriting Requests Based on File Extension
<
1693c1689
< =head2 Internet Exporer 5 favicon.ico 404
---
> More examples:
1699,1700d1694
< =head2 Hiding Extensions for Dynamic Pages
<
1705,1706d1698
< =head2 Serving Static Content Locally and Rewriting Everything Else
<
1749,1777d1740
< =head2 Upgrading mod_perl Heavy Application Instances
<
< When using a light/heavy separation method one of the challenges of
running a production environment is being able to upgrade to newer
versions of mod_perl or your own application. The following method can
be used without having to do a server restart.
<
< Add the following rewrite rule to your httpd.conf file:
<
< RewriteEngine On
< RewriteMap maps txt:/etc/httpd.maps
< RewriteRule ^(.*) http://${maps:appserver}$1 [proxy]
<
< Create the file /etc/httpd.maps and add the following entry:
<
< appserver foo.com:
<
< Mod_rewrite rereads (or checks the mtime of) the file on every request
so the change takes effect immediately. To seamlessly upgrade your
application server to a new version, install a new version on a
different port. After checking for a quality installation, edit
/etc/httpd.maps to point to the new server. After the file is written
the next request the server processes will be redirected to the new
installation.
<
< =head2 Blocking IP Addresses
<
< The following rewrite code blocks IP addresses:
<
< RewriteCond /web/site/var/blocked/REMOTE_ADDR-%{REMOTE_ADDR} -f
< RewriteRule .* http://YOUR-HOST-BLOCKED-FOR-EXCESSIVE-CONSUMPTION
[redirect,last]
<
< To block IP address 10.1.2.3, simply touch
<
< /web/site/var/blocked/REMOTE_ADDR-10.1.2.3
<
< This has an advantage over Apache parsing a long file of addresses in
that the OS is better at a file lookup.
<
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: introducing new code with no perceived user delays?
On Sat, 2003-12-20 at 20:29, Randal L. Schwartz wrote:
> >>>>> "Fred" == Fred Moyer <[EMAIL PROTECTED]> writes:
>
> Fred> < =head2 Blocking IP Addresses
> Fred> <
> Fred> < The following rewrite code blocks IP addresses:
> Fred> <
> Fred> < RewriteCond /web/site/var/blocked/REMOTE_ADDR-%{REMOTE_ADDR} -f
> Fred> < RewriteRule .* http://YOUR-HOST-BLOCKED-FOR-EXCESSIVE-CONSUMPTION
> Fred> [redirect,last]
> Fred> <
> Fred> < To block IP address 10.1.2.3, simply touch
> Fred> <
> Fred> < /web/site/var/blocked/REMOTE_ADDR-10.1.2.3
> Fred> <
> Fred> < This has an advantage over Apache parsing a long file of addresses in
> Fred> that the OS is better at a file lookup.
>
> Hey, that looks familiar. Do I get credit? :)
I'm not familiar with the protocol regarding credit for the mod_perl
documentation but this updated patch gives credit to the contributors :)
1656,1659d1655
< Example code for using mod_rewrite with mod_perl application servers. Several
examples were taken from the mailing list.
<
< =head2 Rewriting Requests Based on File Extension
<
1693c1689
< =head2 Internet Exporer 5 favicon.ico 404
---
> More examples:
1699,1700d1694
< =head2 Hiding Extensions for Dynamic Pages
<
1705,1706d1698
< =head2 Serving Static Content Locally and Rewriting Everything Else
<
1749,1777d1740
< =head2 Upgrading mod_perl Heavy Application Instances
<
< Contributed to the mailing list on 12/18/03 by Rob Nagler
< When using a light/heavy separation method one of the challenges of running a
production environment is being able to upgrade to newer versions of mod_perl or your
own application. The following method can be used without having to do a server
restart.
<
< Add the following rewrite rule to your httpd.conf file:
<
< RewriteEngine On
< RewriteMap maps txt:/etc/httpd.maps
< RewriteRule ^(.*) http://${maps:appserver}$1 [proxy]
<
< Create the file /etc/httpd.maps and add the following entry:
<
< appserver foo.com:
<
< Mod_rewrite rereads (or checks the mtime of) the file on every request so the change
takes effect immediately. To seamlessly upgrade your application server to a new
version, install a new version on a different port. After checking for a quality
installation, edit /etc/httpd.maps to point to the new server. After the file is
written the next request the server processes will be redirected to the new
installation.
<
< =head2 Blocking IP Addresses
<
< Contributed to the mailing list on 12/18/03 by Randal L. Schwartz
< The following rewrite code blocks IP addresses:
<
< RewriteCond /web/site/var/blocked/REMOTE_ADDR-%{REMOTE_ADDR} -f
< RewriteRule .* http://YOUR-HOST-BLOCKED-FOR-EXCESSIVE-CONSUMPTION [redirect,last]
<
< To block IP address 10.1.2.3, simply touch
<
< /web/site/var/blocked/REMOTE_ADDR-10.1.2.3
<
< This has an advantage over Apache parsing a long file of addresses in that the OS is
better at a file lookup.
<
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [RELEASE CANDIDATE] please test mod_perl-1.99_13-dev.tar.gz
On Sat, 2004-03-06 at 03:18, Andrew Wyllie wrote: > All tests passed on FreeBSD-5.2, Perl-5.8.3, Apache-2.0.48 > All tests also passed on Linux 2.4.20-gentoo-r9, Perl-5.8.3, Apache-2.0.48! (threads not enabled) Thanks Stas! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Mod_perl blog recommendations
Hello mod_perl list, I'm looking for simple mod_perl blog which uses the PostgreSQL database. Doesn't have to be fancy, basic requirements are posting news updates without using html tags and ease of use. Any ideas? Thanks, Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Server fails to warm up during make test
Make test and 't/TEST -start' is timing out for me on Darwin 7.3.0, mp1_99_13, Perl 5.8.3, Apache 2.0.49. I've dug around on the list and the site but maybe I've missed something simple here. Advice on the next step in determining the problem or even the solution is much appreciated. -8<-- Start Bug Report 8<-- 1. Problem Description: forbin:~/dev/src/modperl/mod_perl-1.99_13 fredmoyer$ t/TEST -start [warning] setting ulimit to allow core files ulimit -c unlimited; /Users/fredmoyer/dev/perl-5.8.3/bin/perl /Users/fredmoyer/dev/src/modperl/mod_perl-1.99_13/t/TEST -start /Users/fredmoyer/dev/httpd-2.0.49_mp-1.99.13/bin/httpd -d /Users/fredmoyer/dev/src/modperl/mod_perl-1.99_13/t -f /Users/fredmoyer/dev/src/modperl/mod_perl-1.99_13/t/conf/httpd.conf -D APACHE2 using Apache/2.0.49 (prefork MPM) waiting 120 seconds for server to start: .[Tue Apr 13 12:30:24 2004] [info] 28 Apache:: modules loaded [Tue Apr 13 12:30:24 2004] [info] 5 APR:: modules loaded [Tue Apr 13 12:30:24 2004] [info] base server + 16 vhosts ready to run tests waiting 120 seconds for server to start: ok (waited 1 secs) server localhost:8529 started server localhost:8530 listening (TestModperl::merge) ... still waiting for server to warm up: .. the server is down, giving up after 121 secs [ error] failed to start server! (please examine t/logs/error_log) forbin:~/dev/src/modperl/mod_perl-1.99_13/t/logs fredmoyer$ tail -F error_log END in modperl_extra.pl, pid=11648 [Tue Apr 13 12:30:25 2004] [notice] Apache/2.0.49 (Unix) mod_perl/1.99_13 Perl/v5.8.3 configured -- resuming normal operations [Tue Apr 13 12:30:25 2004] [info] Server built: Apr 13 2004 11:25:15 [Tue Apr 13 12:30:25 2004] [debug] prefork.c(955): AcceptMutex: posixsem (default: posixsem) 2. Used Components and their Configuration: *** mod_perl version 1.9913 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS => /Users/fredmoyer/dev/httpd-2.0.49_mp-1.99.13/bin/apxs MP_COMPAT_1X=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /Users/fredmoyer/dev/httpd-2.0.49_mp-1.99.13/bin/httpd -V Server version: Apache/2.0.49 Server built: Apr 13 2004 11:25:15 Server's Module Magic Number: 20020903:7 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_POSIXSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/Users/fredmoyer/dev/httpd-2.0.49_mp-1.99.13" -D SUEXEC_BIN="/Users/fredmoyer/dev/httpd-2.0.49_mp-1.99.13/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** /Users/fredmoyer/dev/perl-5.8.3/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=darwin, osvers=7.3.0, archname=darwin-2level uname='darwin forbin.redhotpenguin.com 7.3.0 darwin kernel version 7.3.0: fri mar 5 14:22:55 pst 2004; root:xnuxnu-517.3.15.obj~4release_ppc power macintosh powerpc ' config_args='-Dprefix=~/dev/perl-5.8.3' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1495)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this bina
[mp2] [solved] Re: Server fails to warm up during make test
On Apr 13, 2004, at 12:40 PM, Fred Moyer wrote: Make test and 't/TEST -start' is timing out for me on Darwin 7.3.0, mp1_99_13, Perl 5.8.3, Apache 2.0.49. I've dug around on the list and the site but maybe I've missed something simple here. Advice on the next step in determining the problem or even the solution is much appreciated. I got past this by using the cvs version of mp2. Doh! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Installing on Apache 2.0.49
I'm beginning my endeavor into the world of mod_perl and so-far not-so-good. I can't seem to get it to load. I have Apache 2.0.49 and mod_perl distribution 1.99_13 and it's all running on a Linux 9.0 box. I ran the command # perl Makefile.PL MP_APXS=/usr/sbin/apxs it ran fine Where did you install Apache 2.0.49? You are building mod_perl against the default Red Hat Apache installation (/usr/sbin/apxs) which is a couple versions earlier than 2.0.49. Any suggestions? Build mod_perl against your Apache 2.0.49 installation # perl Makefile.PL MP_APXS=/where/you/installed/2.0.49/bin/apxs -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Getting help for MasonX::Apache2Handler
2) Note that your libapreq2 had been installed under Apache2. This scheme is used to isolate Apache2-specific code from Apache1 code. On my machine I do not have Apache1 and everything is installed w/o the Apache2 directory. The 'use Apache2 ();' directive prepends direcories in the @INC array with Apache2/ (I think). Maybe my Makefile.PL needs a 'use Apache2 ();' - but I am not sure what will happen during the make and make install. Adding 'use Apache2 ();' to the Makefile.PL fixed the problem. Thanks! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] Re: Getting help for MasonX::Apache2Handler
On Apr 16, 2004, at 10:35 AM, Fred Moyer wrote: 2) Note that your libapreq2 had been installed under Apache2. This scheme is used to isolate Apache2-specific code from Apache1 code. On my machine I do not have Apache1 and everything is installed w/o the Apache2 directory. The 'use Apache2 ();' directive prepends direcories in the @INC array with Apache2/ (I think). Maybe my Makefile.PL needs a 'use Apache2 ();' - but I am not sure what will happen during the make and make install. Adding 'use Apache2 ();' to the Makefile.PL fixed the problem. Thanks! Addendum: The 'perl Makefile.PL' statement ran properly without errors on Linux 2.6.3 but on Darwin 7.0.3 building the Makefile generated the following error. This occurs with the latest releases as well as cvs tips of apreq2 and mp2. Perl 5.8.3 and httpd-2.0.49 were used. Checking if your kit is complete... Looks good dyld: perl Undefined symbols: /Users/fredmoyer/dev/perl-5.8.3/lib/site_perl/5.8.3/darwin-2level/auto/ APR/Table/Table.bundle undefined reference to _modperl_hash_tie expected to be defined in a dynamic image /Users/fredmoyer/dev/perl-5.8.3/lib/site_perl/5.8.3/darwin-2level/auto/ APR/Table/Table.bundle undefined reference to _modperl_hash_tied_object expected to be defined in a dynamic image Trace/BPT trap -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] [solved] Re: Getting help for MasonX::Apache2Handler
On Apr 17, 2004, at 1:03 AM, Stas Bekman wrote:
Beau E. Cox wrote:
[...]
Linux version 2.6.5 (Beau E. Cox on @cathy.beaucox.com)
(gcc version 3.3.3) #1 Mon Apr 5 22:15:29 HST 2004
I did this:
$ export RTLD_NOW=1
$ perl Makefile.PL
[...]
Writing Makefile for MasonX::Apache2Handler
$ set|grep RTLD
RTLD_NOW=1
Everything ok. Can't seem to reproduce your problem, Fred.
That means that Makemaker is doing something different on OSX, than
Linux. Fred, try adding this at the very top of your Makefile.PL and
that should show you who tries to load APR/Table.pm
BEGIN {
use Carp;
$SIG{__DIE__} = \&Carp::confess;
}
The error statement is being thrown while requiring Apache::Cookie in
MakeMaker. I was able to verify this with a test script requiring
Apache::Cookie. This problem is specific to apreq2 on Darwin, I'll
take this issue to the appropriate list.
Thanks for your help guys. Sorry for the false alarm Beau.
MasonX::Apache2Handler is working great on Linux.
Fred
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $r->auth_name
Is there an mp2 implementation of $r->auth_name? I'm working with Apache::AuthCookie in a native mp2 environment and am getting an error message of: I believe this module has been ported to mp2 already. you might want to check the archives so you don't end up doing more work than you need. I followed the threads to http://marc.theaimsgroup.com/?l=apache-modperl&m=105264164428847&w=2 Most of this I got working. Can't locate class method 'Apache::RequestRec::auth_name' via package 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18 I've found references to $r->auth_name and ap_auth_name in the source but have not come across it in the api docs. you need to use Apache::Access (); first. Aha, the missing piece. Thanks! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] $r->auth_name
Greetings, Is there an mp2 implementation of $r->auth_name? I'm working with Apache::AuthCookie in a native mp2 environment and am getting an error message of: Can't locate class method 'Apache::RequestRec::auth_name' via package 'Apache::ReqestRec' at Apache/AuthCookie.pm line 18 I've found references to $r->auth_name and ap_auth_name in the source but have not come across it in the api docs. TIA, Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Need a little help with this one
> I have a file /var/www/cgi-bin/tryit.cgi:
> #! /usr/local/bin/perl
> # tryit.pl
>
> use Acrobat::FDF;
...
> $currentField=$inFDF->NextFieldName("");
...
> [Sat Jul 10 20:04:42 2004] [error] Can't call method "NextFieldName" on an
> undefined value at /usr/local/apache/htdocs/online_testing/perl/tryit.pl
> line 13.\n
I am unfamiliar with the api for Acrobat::FDF, however relying on previous
encounters with this error message I think the NextFieldName method
requires a defined input parameter.
Can you provide us with the documentation from Acrobat::FDF for the
NextFieldName method? I didn't see this package on CPAN so I am just
guessing at this point.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: accessing loaded modules from other modules
> just a quick one:How can I access loaded modules from other modules using > mod_perl, i.e. say that I am running module contacts.pm within modperl, > and I want from ContactPersons.pm access the contacts module, given that > the two modules/packages are loaded separately. > any advice appreciated! I suggest the following entry in module 'contacts.pm' use base qw( ContactsPersons ); Alternatively you could: push @ISA, qw(ContactsPerson); if you are more concerned with encapsulation of package variables. But I think the first suggestion is generally more commonly used by mod_perl engineers. Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] $r->method and $r->method_number set methods deprecated?
Greetings,
I use a CPAN module in my code that uses $r->method and $r->method_number
to set the request method and method numbers. When I upgraded to
1.99_15-dev the module can no longer set the method and number, only get
it (1). Are the set methods are deprecated, or are they in the works
still? If they are deprecated I will refactor the module for 1.99_15.
Thanks for your time,
Fred
(1)
Existing code for reference which works under 1.99_14 but not 1.99_15:
sub _convert_to_get {
...
$r->method('GET');
$r->method_number(M_GET);
...
}
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $r->method and $r->method_number set methods deprecated?
> Thanks for the spot Fred. > > The issue was is that we had almost all accessors settable, as I worked through those I've made of them read-only, which wasn't always right. Please try the current cvs or the patch below [1]. Current cvs did the trick, thanks. > Now if you could go through the mp2 accessors and check if I've missed some other (and which should be read/write), that would be a lot of help. It's probably the easiest if you use the pod manpages from here: http://perl.apache.org/download/docs.html > > The mp1 methods are documented here: > modperl-docs/src/docs/1.0/api/Apache.pod > > The corresponding mp2 methods will be here: > modperl-docs/src/docs/2.0/api/Apache/* Sure I can do that no problem. Will probably add tests to the TestAPI packages to determine if any other read/write accessors missing unless there is a more efficient way that I'm not seeing here. > > Thanks. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Error on Apache::Request install [mp2]
> I have Apache 2 and Mod Perl 2 already install though someone else installed > them for me. > Any idea what's up and how I can located this apxs stuff? They didn't install httpd-devel which contains apxs, hence it is not being found by libapreq2. Install the httpd-devel rpm via up2date or yum. Or install apache from source with './configure --enable-so'. Then read this: http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Installation After you've read that and installed the latest (1.99_15) mod_perl2 start over with libapreq2. All you need to do is type 'perl Makefile.PL', then 'make; make test; make install'. Report any test failures to the libapreq list. HTH, Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] 1.99_16 test failure
Greetings, I encountered a test failure for t/lookup_uri.t on 1.99_16 under perl 5.8.5 and httpd 2.0.50. Same test failure occurs under cvs head. I dug into the code but don't understand enough about it to provide a patch right now. -8<-- Start Bug Report 8<-- 1. Problem Description: During 'make test' [Mon Aug 23 20:07:59 2004] [error] [client 127.0.0.1] Use of uninitialized value in string eq at /home/fred/dev/cvs/modperl-2.0/t/response/TestAPI/lookup_uri.pm line 30. 2. Used Components and their Configuration: *** mod_perl version 1.9916 *** using /home/fred/dev/cvs/modperl-2.0/lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /home/fred/dev/httpd2/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 MP_USE_STATIC => 1 *** /home/fred/dev/httpd2/bin/httpd -V Server version: Apache/2.0.50 Server built: Aug 5 2004 01:46:05 Server's Module Magic Number: 20020903:8 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/home/fred/dev/httpd2" -D SUEXEC_BIN="/home/fred/dev/httpd2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** (apr|apu)-config linking info -L/home/fred/dev/httpd2/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl -L/home/fred/dev/httpd2/lib -laprutil-0 -lgdbm -ldb-4.2 -lexpat *** /home/fred/dev/perl/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 5) configuration: Platform: osname=linux, osvers=2.6.7-gentoo-r8, archname=i686-linux uname='linux fishman 2.6.7-gentoo-r8 #4 sat jul 24 12:49:28 edt 2004 i686 intel(r) pentium(r) m processor 1600mhz genuineintel gnulinux ' config_args='-Dprefix=/home/fred/dev/perl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe' ccversion='', gccversion='3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 4 2004 23:49:58 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /home/fred/dev/perl/lib/5.8.5/i686-linux /home/fred/dev/perl/lib/5.8.5 /home/fred/dev/perl/lib/site_perl/5.8.5/i686-linux /home/fred/dev/perl/lib/site_perl/5.8.5 /home/fred/dev/perl/lib/site_perl . *** Packages of interest status: Apache::Request: 2.04-dev CGI: 3.05 LWP: 5.800 mod_perl : 1.9915 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Tue Aug 24 01:45:39 2004 GMT. -8<-- End Bug Report --8<-- Note: Complete the rest of the details and post this bug report to modperl perl.apache.org. To subscribe to the list send an empty email to [EMAIL PROTECTED] -- TaperFriendlyMusic.org Where the music never stops... http://www.taperfriendlymusic.org -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] 1.99_16 test failure
>> During 'make test' >> >> [Mon Aug 23 20:07:59 2004] [error] [client 127.0.0.1] Use of >> uninitialized >> value in string eq at >> /home/fred/dev/cvs/modperl-2.0/t/response/TestAPI/lookup_uri.pm line 30. > > Fred, please read: > http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures > Got the same error first time around with verbose test settings but runs fine now after the second verbose run. Strange because I was able to replicate it a couple times from scratch yesterday. Sorry for the false alarm - computer probably needs a break. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] 1.99_16 problem
> Can't locate object method "server_hostname" via package
> "Apache::ServerRec" at
> ... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
> at -e line 0\n\teval {...} called at -e line 0\n
>
> The line concerned is:
>
> my $host_name = $r->server->server_hostname;
http://perl.apache.org/docs/2.0/api/Apache/ServerRec.html#C_server_hostname_
HTH,
Fred
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] 1.99_16 problem
>> Can't locate object method "server_hostname" via package
>> "Apache::ServerRec" at
>> ... 300.\n\t..., 'Apache::RequestRec=SCALAR(0x881968)') called
>> at -e line 0\n\teval {...} called at -e line 0\n
>>
>> The line concerned is:
>>
>> my $host_name = $r->server->server_hostname;
>
> http://perl.apache.org/docs/2.0/api/Apache/ServerRec.html#C_server_hostname_
That answer I just gave was not obvious in its statement of the solution
to your problem. What you appear to be missing is:
use Apache::ServerRec();
Thank you,
Fred
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Compatibility issue: Apache::ParseFormData vs. 1.99_15
> - removed:
>
> remaining - this method is not needed if the deprecated
> $r->client_block methods aren't used, (use $r->read
> $r->instead)
>
> This violates the compatibility with Apache::ParseFormData, which becomes
> unusable. Currently this module is the only alternative to libapreq2,
> which is still in development phase.
>
> Would be good if you undo the removal until libapreq2 release comes out.
Try this patch on ParseFormData instead. Works for me using the suggested
implementation in the docs. No sense in backtracking...
--- ParseFormData.pm.orig 2004-09-02 14:15:17.827899688 -0400
+++ ParseFormData.pm2004-09-02 14:13:37.898091328 -0400
@@ -131,8 +131,6 @@
my $args = shift;
my $buf = "";
- $r->setup_client_block;
- $r->should_client_block or return '';
my $ct = $r->headers_in->get('content-type');
if($args->{'disable_uploads'} && index($ct, "multipart/form-data")
> -1) {
@@ -152,7 +150,7 @@
if($ct =~ /^multipart\/form-data; boundary=(.+)$/) {
my $boundary = $1;
my $lenbdr = length("--$boundary");
- $r->get_client_block($buf, $lenbdr+2);
+ $r->read($buf, $lenbdr+2);
$buf = substr($buf, $lenbdr);
$buf =~ s/[\n\r]+//;
my $iter = -1;
@@ -193,7 +191,7 @@
$r->pnotes('upload' => \%uploads);
} else {
my $len = $r->headers_in->get('content-length');
- $r->get_client_block($buf, $len);
+ $r->read($buf, $len);
&_parse_query($r, $buf) if($buf);
}
return(Apache::OK);
@@ -253,7 +251,7 @@
my $buff = shift;
my ($part, $content) = ($buff, "");
- while($r->get_client_block($buff, $len)) {
+ while($r->read($buff, $len)) {
$part .= $buff;
if($h) {
if($part =~ /\r?\n\r?\n/) {
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Compatibility issue: Apache::ParseFormData vs. 1.99_15
> Fred, thanks for assistance, but your patch does not touch line 144 in > ParseFormData.pm: Thanks for the spot. My point though was that if you're not comfortable with using the current libapreq release because it's developer release, then making the changes to Apache::ParseFormData for compatability with the current mod_perl version is not that difficult. And you seem to have a handle on what issues need to be addressed. Restoring deprecated functions in mod_perl2 for backwards compatability isn't the answer. The latest libapreq snapshot though has been working great for me though, and I use it everyday as the main workhorse of my current project. I would highly recommend it. Fred -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-AuthenNTLM-2.07 and ModPerl 1.99_16
> I really have no idea about Apache-AuthenNTLM but to make it working
> again you could apply the patch below and rebuilt your mod-perl.
> As far
> as I can tell from the last mail from Stas it's going to be
> read/writeable in future if one volunteers to write tests :-).
I originally suggested that change as a result of reviewing the map
structures after running into this same problem on a different method of a
read only accessor breaking an existing module. So I am due some flak
here for suggesting other methods be read-only, as it has broken something
else. Maybe I can volunteer to write tests for those methods as a way of
making amends.
Here's a patch for AuthenNTLM.pm which uses $conn->notes, instead of
modifying $conn->remote_host, to compare the connections. I don't have a
working NTLM setup but maybe give this a go and see how it works.
--- AuthenNTLM.pm 2004-09-20 12:44:03.028383768 -0400
+++ AuthenNTLM.pm 2004-09-20 12:58:02.975692368 -0400
@@ -542,14 +542,23 @@
# The check is done by slightly changing the remote_host member, which
# persists as long as the connection does
# This has to be reworked to work with Apache 2.0
-if (ref ($cache) ne $class || $$conn != $cache -> {connectionid} ||
$conn ->
remote_host ne $cache->{remote_host})
-{
- $conn -> remote_host ($conn -> remote_host . ' ') ;
-$self = {connectionid => $$conn, remote_host => $conn ->
remote_host} ;
-bless $self, $class ;
- $cache = $self ;
- print STDERR "[$$] AuthenNTLM: Setup new object\n" if ($debug) ;
+if (ref ($cache) ne $class || $$conn != $cache->{connectionid} ||
+(!MP2 && $conn->remote_host ne $cache->{remote_host}) ||
+(MP2 && $conn->notes ne $cache->{notes}))
+{
+if (!MP2) {
+$conn->remote_host ($conn -> remote_host . ' ') ;
+$self = {connectionid => $$conn,
+ remote_host => $conn -> remote_host} ;
}
+elsif (MP2) {
+$conn->notes($$self);
+$self = {connectionid => $$conn, notes => $conn->notes};
+}
+bless $self, $class ;
+$cache = $self ;
+print STDERR "[$$] AuthenNTLM: Setup new object\n" if ($debug) ;
+}
else
{
$self = $cache ;
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Shopping Cart Software
> Use clickcartpro its Perl, its easy , and it rocks! > Interchange is also worth taking a look at. http://www.icdevgroup.org/ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Shopping Cart Software
Robert Ferney wrote: The question for me is, do they work under Apache2 or are they only working for Apache 1.3 There's a how-to here for installing Interchange with PostgreSQL and mod_perl 2. I haven't used it but it looks thorough :) http://www.w3trader.com/Interch/Interchange-PostgreSQL.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl and 64-bit linux
> I am considering upgrading to a 64-bit Opteron-based machine running RH > linux. Using perl 5.8, apache 2, mod_perl. Has anyone run into any > problems running their mod_perl applications on a 64-bit box with a > 64-bit linux OS? I ran a mission critical web-app using Apache2/mod_perl2, and an sql database on Opteron using FC2 with non-threaded perl 5.8.5. I built apache, mod_perl, and perl from source.We didn't have any 64-bit related problems with the web app. The opteron is a very fast machine. Now, to go off the mod_perl topic for a few sentences, we did experience some crashes due to i/o intensive batch operations. The code was opening thousands of file handles very quickly. I found one relevant link on google which unfortunately I don't have access to anymore, but it cited a crash occurring while using bonnie++ for benchmarking on opteron. We had another issue with occasional segfaults of long running (7+ days) programs which consumed enormous (15G+) amounts of memory. Suffice to say though, we were going beyond normal usage, and encountered a few dragons. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Problem installing mod_perl2 on Clarkconnect
On Mon, Jun 15, 2009 at 8:19 AM, Mike OK wrote:
> t/hooks/authen_basic.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 4
> t/hooks/authz.t (Wstat: 0 Tests: 4 Failed: 1)
> Failed test: 4
> Files=238, Tests=2557, 193 wallclock secs ( 3.25 usr 0.91 sys + 151.19 cusr
> 26.60 csys = 181.95 CPU)
> Result: FAIL
> Failed 2/238 test programs. 2/2557 subtests failed.
Pretty sure those are fixed in 2.0.5-dev
> I ignored the error and forced an install as root anyway and my machine says
> mod_perl2 is up to date. When I restart apache, I get no mod_perl enabled
> message in error_log.
You could try adding this after the LoadModule directive:
PerlModule Apache2::Const;
PerlChildInitHandler sub { say("process $$ is born to serve"); return
Apache2::Const::OK }
or some variation on that, and you'll see a message in the log for
each mod_perl enabled child process that starts up
>
> I have include the loadmodule line inside of httpd.conf.
> LoadModule perl_module modules/mod_perl.so
>
> /httpd/logs/error_log
> [Sun Jun 14 22:43:41 2009] [notice] Apache configured -- resuming normal
> operations
> [Mon Jun 15 00:12:24 2009] [notice] caught SIGTERM, shutting down
> [Mon Jun 15 00:12:24 2009] [notice] suEXEC mechanism enabled (wrapper:
> /usr/sbin/suexec)
> [Mon Jun 15 00:12:24 2009] [notice] Digest: generating secret for digest
> authentication ...
> [Mon Jun 15 00:12:24 2009] [notice] Digest: done
> [Mon Jun 15 00:12:24 2009] [notice] LDAP: Built with OpenLDAP LDAP SDK
> [Mon Jun 15 00:12:24 2009] [notice] LDAP: SSL support unavailable
> [Mon Jun 15 00:12:24 2009] [notice] Apache configured -- resuming normal
> operations
>
> Any help would be greatly appreciated
> Thanks Mike
>
>
Re: Problem installing mod_perl2 on Clarkconnect
On Mon, Jun 15, 2009 at 4:04 PM, Mike OK wrote:
> Thanks for the reply Fred. Today I upgraded from apache 2.0 to 2.2 and
> still are having the test errors. I will continue through and install
> without test to see what happens.
You are probably fine unless you have some complex authentication code
that isn't working ok. My app uses some auth handlers and didn't have
any issues with those failures under 2.0.4.
> Any idea where I can find 2.0.5-dev?? Mike
You can pull it from subversion here:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
>
>
> - Original Message - From: "Fred Moyer"
> To: "Mike OK"
> Cc:
> Sent: Monday, June 15, 2009 6:52 PM
> Subject: Re: Problem installing mod_perl2 on Clarkconnect
>
>
>> On Mon, Jun 15, 2009 at 8:19 AM, Mike OK wrote:
>>>
>>> t/hooks/authen_basic.t (Wstat: 0 Tests: 4 Failed: 1)
>>> Failed test: 4
>>> t/hooks/authz.t (Wstat: 0 Tests: 4 Failed: 1)
>>> Failed test: 4
>>> Files=238, Tests=2557, 193 wallclock secs ( 3.25 usr 0.91 sys + 151.19
>>> cusr
>>> 26.60 csys = 181.95 CPU)
>>> Result: FAIL
>>> Failed 2/238 test programs. 2/2557 subtests failed.
>>
>> Pretty sure those are fixed in 2.0.5-dev
>>
>>> I ignored the error and forced an install as root anyway and my machine
>>> says
>>> mod_perl2 is up to date. When I restart apache, I get no mod_perl enabled
>>> message in error_log.
>>
>> You could try adding this after the LoadModule directive:
>>
>> PerlModule Apache2::Const;
>> PerlChildInitHandler sub { say("process $$ is born to serve"); return
>> Apache2::Const::OK }
>>
>> or some variation on that, and you'll see a message in the log for
>> each mod_perl enabled child process that starts up
>>
>>
>>
>>>
>>> I have include the loadmodule line inside of httpd.conf.
>>> LoadModule perl_module modules/mod_perl.so
>>>
>>> /httpd/logs/error_log
>>> [Sun Jun 14 22:43:41 2009] [notice] Apache configured -- resuming normal
>>> operations
>>> [Mon Jun 15 00:12:24 2009] [notice] caught SIGTERM, shutting down
>>> [Mon Jun 15 00:12:24 2009] [notice] suEXEC mechanism enabled (wrapper:
>>> /usr/sbin/suexec)
>>> [Mon Jun 15 00:12:24 2009] [notice] Digest: generating secret for digest
>>> authentication ...
>>> [Mon Jun 15 00:12:24 2009] [notice] Digest: done
>>> [Mon Jun 15 00:12:24 2009] [notice] LDAP: Built with OpenLDAP LDAP SDK
>>> [Mon Jun 15 00:12:24 2009] [notice] LDAP: SSL support unavailable
>>> [Mon Jun 15 00:12:24 2009] [notice] Apache configured -- resuming normal
>>> operations
>>>
>>> Any help would be greatly appreciated
>>> Thanks Mike
>>>
>>>
>>
>
>
>
Re: Apache Mobile Filter
On Wed, Jul 8, 2009 at 2:29 PM, Idel Fuschini wrote: > I have published the last version of "Apache Mobile Filter". > > For more info: http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html Looks interesting, but for future reference, when posting links to the list, you might want to consider sending your email in plain text rather than html: http://perl.apache.org/maillist/email-etiquette.html#Post_in_PLAIN_TEXT Also, I think people are generally more accepting of links that are openly using a known redirect tracker such as bit.ly, rather than embedding a hidden redirect link using html as you did here [1]. Your email will probably get out to more people on the list, as some email clients will identify this technique and mark it as spam or a phishing message. Having been the victim of a CRSF attack that used this method, it tends to stand out as a red flag in my view when I recognize it (but that's just me, I don't speak for the list in general). [1] http://www.linkedin.com/redirect?url=3Dhttp%= 3A%2F%2Fwww%2Eidelfuschini%2Eit%2Fit%2Fapache-mobile-filter-v2x%2Ehtml&= urlhash=3D0M2h&_t=3Ddisc_detail_link" target=3D"_blank">http://www.idel= fuschini.it/it/apache-mobile-filter-v2x.html > Demo link: http://apachemobilefilter.nogoogle.it/php_test.php > > -- > Idel >
Re: Apache Mobile Filter
Thanks :) I am currently looking into a solution to do dynamic image resizing for mobile devices, so this is interesting to me. Can you provide some more documentation in the pod for the module so that I can see how to use it? Particularly this module: http://search.cpan.org/~ifuschini/Apache2-WURFLFilter-2.03/lib/Apache2/ImageRenderFilter.pm A snippet that I could add to my httpd.conf would be ideal. On Wed, Jul 8, 2009 at 4:05 PM, Idel Fuschini wrote: > Fred, > You have right, and thanks for the reporting. I just did a cut and paste > from a my post on linkedin. So I try to re-send my question: > > "I have published the last version of "Apache Mobile Filter". > > The Apache Mobile Filter allows you to access WURFL from any programming > language, not just Java and php that is traditionally used for dynamic > mobile web sites. > > The module detects the mobile device and passes the WURFL capabilities on to > the other web application as environment variables. It can also be used to > resize images on the fly to adapt to the screen size of the mobile device. > > Try it and let me know your opinion. Do you think could be an intersting > mobile solution for the Apache Software Foundation > > For download the package: > http://search.cpan.org/~ifuschini/Apache2-WURFLFilter-2.03/ > > For more info: http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html > Demo link: http://apachemobilefilter.nogoogle.it/php_test.php"; > > Sorry again for the mistake. > > > 2009/7/9 Fred Moyer >> >> On Wed, Jul 8, 2009 at 2:29 PM, Idel Fuschini >> wrote: >> > I have published the last version of "Apache Mobile Filter". >> > >> > For more info: >> > http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html >> >> Looks interesting, but for future reference, when posting links to the >> list, you might want to consider sending your email in plain text >> rather than html: >> >> http://perl.apache.org/maillist/email-etiquette.html#Post_in_PLAIN_TEXT >> >> Also, I think people are generally more accepting of links that are >> openly using a known redirect tracker such as bit.ly, rather than >> embedding a hidden redirect link using html as you did here [1]. >> >> Your email will probably get out to more people on the list, as some >> email clients will identify this technique and mark it as spam or a >> phishing message. Having been the victim of a CRSF attack that used >> this method, it tends to stand out as a red flag in my view when I >> recognize it (but that's just me, I don't speak for the list in >> general). >> >> [1] >> http://www.linkedin.com/redirect?url=3Dhttp%= >> >> 3A%2F%2Fwww%2Eidelfuschini%2Eit%2Fit%2Fapache-mobile-filter-v2x%2Ehtml&= >> urlhash=3D0M2h&_t=3Ddisc_detail_link" >> target=3D"_blank">http://www.idel= >> fuschini.it/it/apache-mobile-filter-v2x.html >> >> >> >> >> > Demo link: http://apachemobilefilter.nogoogle.it/php_test.php >> > >> > -- >> > Idel >> > > > > > -- > Idel > = > E-Mail: idel.fusch...@gmail.com > Web Site: http://www.idelfuschini.it > OpenSource Project: Apache Mobile Filter - > http://www.idelfuschini.it/apache-mobile-filter-v2x.html > Test Page: http://apachemobilefilter.nogoogle.it/php_test.php > >
Re: Apache Mobile Filter
On Thu, Jul 9, 2009 at 9:49 AM, Idel Fuschini wrote: > Hi Fred,> I follow your suggest, now I attach (only for you) my presentation of the Apache Mobile Filter where is explane the > configuration. > The ImageRenderFilter can work only with the WURFLFIlter. Idel, Please cc the mod_perl list on all responses. Unfortunately, I don't always have the time to reply to individual messages, and rely on the wisdom of others on the list to help provide support and respond to questions. What I was asking for with regards to more documentation, was plain old documentation (POD, http://en.wikipedia.org/wiki/Plain_Old_Documentation) Something like: =head2 SYNOPSIS In your httpd.conf: PerlLoadModule MyModule SetHandler modperl PerlResponseHandler MyModule =cut I can't speak for everyone on the list, but I think you'll have a hard time selling people on your module unless you have some basic documentation in the POD showing how to use it. Presentations and pdfs are excellent supplements, but personally I am not inclined to use a module unless it has some bare bones documentation in it, or I know the author's work. > The WurflFilter detect the device and passes to the other module the > capability of devices. > > Idel > > > 2009/7/9 Fred Moyer > >> Thanks :) I am currently looking into a solution to do dynamic image >> resizing for mobile devices, so this is interesting to me. >> >> Can you provide some more documentation in the pod for the module so that >> I can see how to use it? >> >> Particularly this module: >> >> >> http://search.cpan.org/~ifuschini/Apache2-WURFLFilter-2.03/lib/Apache2/ImageRenderFilter.pm<http://search.cpan.org/%7Eifuschini/Apache2-WURFLFilter-2.03/lib/Apache2/ImageRenderFilter.pm> >> >> A snippet that I could add to my httpd.conf would be ideal. >> >> >> On Wed, Jul 8, 2009 at 4:05 PM, Idel Fuschini >> wrote: >> > Fred, >> > You have right, and thanks for the reporting. I just did a cut and paste >> > from a my post on linkedin. So I try to re-send my question: >> > >> > "I have published the last version of "Apache Mobile Filter". >> > >> > The Apache Mobile Filter allows you to access WURFL from any programming >> > language, not just Java and php that is traditionally used for dynamic >> > mobile web sites. >> > >> > The module detects the mobile device and passes the WURFL capabilities >> on to >> > the other web application as environment variables. It can also be used >> to >> > resize images on the fly to adapt to the screen size of the mobile >> device. >> > >> > Try it and let me know your opinion. Do you think could be an >> intersting >> > mobile solution for the Apache Software Foundation >> > >> > For download the package: >> > http://search.cpan.org/~ifuschini/Apache2-WURFLFilter-2.03/<http://search.cpan.org/%7Eifuschini/Apache2-WURFLFilter-2.03/> >> > >> > For more info: >> http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html >> > Demo link: http://apachemobilefilter.nogoogle.it/php_test.php"; >> > >> > Sorry again for the mistake. >> > >> > >> > 2009/7/9 Fred Moyer >> >> >> >> On Wed, Jul 8, 2009 at 2:29 PM, Idel Fuschini >> >> wrote: >> >> > I have published the last version of "Apache Mobile Filter". >> >> > >> >> > For more info: >> >> > http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html >> >> >> >> Looks interesting, but for future reference, when posting links to the >> >> list, you might want to consider sending your email in plain text >> >> rather than html: >> >> >> >> >> http://perl.apache.org/maillist/email-etiquette.html#Post_in_PLAIN_TEXT >> >> >> >> Also, I think people are generally more accepting of links that are >> >> openly using a known redirect tracker such as bit.ly, rather than >> >> embedding a hidden redirect link using html as you did here [1]. >> >> >> >> Your email will probably get out to more people on the list, as some >> >> email clients will identify this technique and mark it as spam or a >> >> phishing message. Having been the victim of a CRSF attack that used >> >> this method, it tends to stand out as a red flag in my view when I >> >> recognize it (but that's just me, I don't speak for the list in >> >> g
Apache::Bootstrap 0.07-rc1 available for testing
I'd love it if you could take this rc for a spin and report back. Passing all tests on OS X 10.5, 5.8.8, 2.2.6 and Centos 5.2, 5.8.9, 2.2.8. I resolved some issues while implementing this version for Apache::Dispatch. Changes since 0.06 - fix syntax error in params validation in new (mp2 param unchecked) - warn instead of dying in new if a module is not present, and then decide if any modules are present to create a new bootstrap object http://people.apache.org/~phred/Apache-Bootstrap-0.07-rc1.tar.gz
Re: Apache::Bootstrap 0.07-rc1 available for testing
On Fri, Jul 10, 2009 at 1:48 AM, Cosimo Streppone wrote: > > In data 10 juli 2009 alle ore 00:18:57, Fred Moyer > ha scritto: > >> I'd love it if you could take this rc for a spin and report back. Passing >> all tests on OS X 10.5, 5.8.8, 2.2.6 >> and Centos 5.2, 5.8.9, 2.2.8. > > Test pass on debian etch. > Not sure why it says "minimum version required is 1.31" for Apache::Test. > Does 1.31 exist somewhere? It does not. I do some stuff in there to magically bump up the version of apache test to one above what is installed so that the check_for_apache_test method should fail. Do you have only mod_perl2 installed? Getting the detection to work has been tough, but I think this version may be doing the job correctly. > > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/00-load.ok 1/11# bootstrapping mp1 only > mod_perl not present, cannot bootstrap mp1 at > /var/dev/cosimo/src/Apache-Bootstrap-0.07-rc1/blib/lib/Apache/Bootstrap.pm > line 96. > # bootstrapping mp2 only > # Testing Apache::Bootstrap 0.07-rc1, Perl 5.008008, /usr/bin/perl > Apache::Test version is 1.30, minimum version required is 1.31, tests will be > skipped > t/00-load.ok > 6/11 skipped: various reasons > t/pod-coverageskipped > all skipped: Pod::Coverage 0.18 required for testing POD coverage > t/pod.ok > All tests successful, 1 test and 6 subtests skipped. > Files=3, Tests=12, 0 wallclock secs ( 0.49 cusr + 0.04 csys = 0.53 CPU) > > > -- > Cosimo
[ANNOUNCE] Apache-Bootstrap 0.07
I'm happy to announce the release of Apache::Bootstrap 0.07. This release contains a couple of major bug fixes from 0.07, and this package should now be considered stable enough to use to bootstrap your dual life mod_perl1/mod_perl2 modules. If you've ever had to tussle with the nuances of maintaining a module that works with both mod_perl1 and mod_perl2, you'll appreciate this module. As always, feedback and patches are welcome. Recent changes: 0.07 Mon Jul 13 12:09:00 PST 2009 - fix syntax error in params validation in new (mp2 param unchecked) - warn instead of dying in new if a module is not present, and then decide if any modules are present to create a new bootstrap object The uploaded file Apache-Bootstrap-0.07.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PH/PHRED/Apache-Bootstrap-0.07.tar.gz size: 10197 bytes md5: 2ab06f6e027902e654e363ce74e4336f No action is required on your part Request entered by: PHRED (Fred Moyer) Request entered on: Mon, 13 Jul 2009 19:12:47 GMT Request completed: Mon, 13 Jul 2009 19:13:27 GMT
Re: first time debugging apache/mod_perl Seg fault
On Mon, Jul 13, 2009 at 12:15 PM, Alan McKay wrote: > Hey folks, > > I'm running CentOS 5.2 with a custom built apache not from Yum. > > I am following instructions here > http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped > > and here : > http://perl.apache.org/docs/2.0/devel/debug/c.html#Analyzing_Dumped_Core_Files > > I have mod_perl built with symbols and reproduce my problem, but I'm > not having much luck with gdb. I really have no experience with this > aspect of Linux so am shooting in the dark a bit here. > > I also have no idea whether I'm "threaded" or "unthreaded", so I tried > both of the "curinfo" macros with no luck. > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so You're threaded. What version of Apache and mod_perl are you running here? What configuration options are you using to build apache? > Here is the output of "bt full" which clearly shows a few "my_perl" > entries. But I'm just not clear how to find out what part of our > Perl code is causing the issue. > > (gdb) bt full > #0 0x0044e172 in Perl_cv_const_sv () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #1 0x00442a7c in Perl_yylex () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #2 0x0044b295 in Perl_yyparse () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #3 0x004b8200 in Perl_pp_range () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #4 0x004ba0b2 in Perl_pp_require () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #5 0x004ba7ad in Perl_pp_dofile () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #6 0x0048488f in Perl_runops_standard () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #7 0x00424ffe in Perl_magicname () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #8 0x00429806 in Perl_call_sv () from > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so > No symbol table info available. > #9 0x00140a7f in modperl_callback (my_perl=0x9476458, > handler=0xaccc268, p=0xaf2a840, r=0xaf2a880, s=0xad0bad0, > args=0xbd473e8) at modperl_callback.c:101 > items = > cv = > sp = (SV **) 0xafead24 > status = 0 > #10 0x0014117a in modperl_callback_run_handlers (idx=6, type=4, > r=0xaf2a880, c=0x0, s=0xad0bad0, pconf=0x0, plog=0x0, ptemp=0x0, > run_mode=MP_HOOK_RUN_FIRST) > at modperl_callback.c:262 > my_perl = (PerlInterpreter *) 0x9476458 > interp = (modperl_interp_t *) 0xa965888 > scfg = (modperl_config_srv_t *) 0x8d437b8 > dcfg = (modperl_config_dir_t *) 0xaf2a2e0 > rcfg = (modperl_config_req_t *) 0xaf2b5f0 > handlers = (modperl_handler_t **) 0xaccc298 > p = (apr_pool_t *) 0xaf2a840 > av = (MpAV *) 0xaccc280 > avp = > i = 0 > status = 0 > desc = 0x158cd3 "PerlResponseHandler" > av_args = (AV *) 0xbd473e8 > #11 0x0014180a in modperl_callback_per_dir (idx=6, r=0xaf2a880, > run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:369 > No locals. > #12 0x0013a79f in modperl_response_handler_run (r=0xaf2a880, finish=0) > at mod_perl.c:1000 > retval = > #13 0x0013a96b in modperl_response_handler_cgi (r=0xaf2a880) at > mod_perl.c:1100 > dcfg = (modperl_config_dir_t *) 0xaf2a2e0 > h_stdin = (GV *) 0xc2d7a20 > h_stdout = (GV *) 0xb4ba144 > retval = -1 > rc = > rcfg = (modperl_config_req_t *) 0xaf2b5f0 > my_perl = (PerlInterpreter *) 0x9476458 > interp = (modperl_interp_t *) 0xa965888 > #14 0x08076a79 in ap_run_handler (r=0xaf2a880) at config.c:157 > n = 6 > rv = 40 > #15 0x08079be7 in ap_invoke_handler (r=0xaf2a880) at config.c:372 > handler = 0x0 > result = > old_handler = 0xaccbe38 "perl-script" > ignore = > #16 0x08090798 in ap_process_request (r=0xaf2a880) at http_request.c:258 > ---Type to continue, or q to quit--- > access_status = 0 > #17 0x0808da3b in ap_process_http_connection (c=0xaf1a9d8) at http_core.c:190 > r = (request_rec *) 0xaf2a880 > csd = (apr_socket_t *) 0x0 > #18 0x0807dab9 in ap_run_process_connection (c=0xaf1a9d8) at connection.c:43 > n = 1 > rv = 40 > #19 0x080a3dc5 in child_main (child_num_arg=) at > prefork.c:650 > numdesc = 0 > pdesc = (const apr_pollfd_t *) 0x0 > current_conn = (conn_rec *) 0xaf1a9d8 > csd = (void *) 0xaf1a840 > ptrans = (apr_pool_t *) 0xaf1a800 > allocator = (apr_allocator_t *) 0x9301738 > status = > i = > lr = > pollset = (apr_pollset_t *) 0xaf18850
Re: Issue with Apache2::Request
On Mon, Jul 27, 2009 at 2:44 PM, André Warnier wrote: > Hi. > > Background : > > [Mon Jul 27 22:23:35 2009] [notice] Apache/2.2.9 (Debian) DAV/2 > mod_jk/1.2.26 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal > operations > /usr/sbin/apache2: symbol lookup error: > /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so: undefined symbol: > apreq_handle_apache2 I think you may need this line in your httpd.conf: LoadModule apreq_modulemodules/mod_apreq2.so > > That happens apparently as soon as a module tries to "use" Apache2::Request. > > Apache and mod_perl run fine as long as I don't use Apache2::Request. > > I get the same error, whether Apache 2.2.9 is MPM-prefork or MPM-worker. > The installation/de-installation/re-installation of the Debian modules > brings up nothing special : > Setting up libapreq2 (2.08-5+b1) ... > Setting up libapache2-mod-apreq2 (2.08-5+b1) ... > Setting up libapache2-request-perl (2.08-5+b1) ... > > Any idea anyone ? > > Thanks in advance. > > P.S. If the answer was to be "go ask in a Debian forum", and anyone happened > to know a relevant one, I'm a taker for a ref also. > > > Additional info : > > # perl -V > > Summary of my perl5 (revision 5 version 10 subversion 0) configuration: > Platform: > osname=linux, osvers=2.6.26-1-vserver-amd64, > archname=x86_64-linux-gnu-thread-multi > uname='linux excelsior 2.6.26-1-vserver-amd64 #1 smp sat nov 8 20:24:14 > utc 2008 x86_64 gnulinux ' > config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN > -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr > -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 > -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 > -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 > -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 > -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 > -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl > -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm > -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 > -Dd_dosuid -des' > hint=recommended, useposix=true, d_sigaction=define > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN > -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64', > optimize='-O2 -g', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe > -I/usr/local/include' > ccversion='', gccversion='4.3.2', gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 > libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt > perllibs=-ldl -lm -lpthread -lc -lcrypt > libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0 > gnulibc_version='2.7' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' > cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV > PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL > USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES > USE_PERLIO USE_REENTRANT_API > Built under linux > Compiled at Jan 1 2009 15:42:01 > �...@inc: > /etc/perl > /usr/local/lib/perl/5.10.0 > /usr/local/share/perl/5.10.0 > /usr/lib/perl5 > /usr/share/perl5 > /usr/lib/perl/5.10 > /usr/share/perl/5.10 > /usr/local/lib/site_perl > . >
Re: Is mod_perl dead?
On Mon, Aug 10, 2009 at 7:07 AM, Clinton Gormley wrote: > Dear Igor > > On Mon, 2009-08-10 at 07:40 -0500, Igor Chudov wrote: > >> After looking at this mailing list and asking a question about >> segfaults, and looking at recent posts, I am beginning to become >> concerned that mod_perl is a dead project. I would like to hear >> whether it has a long term future, which I hope is the case, as I do >> not want to rewrite 70,000+ lines of code! > > It is most certainly not a dead project. While there doesn't appear to > be lots of ongoing development, the reason for that is that mod_perl is > pretty much a done project. There is ongoing development, but most of it has been focused on bugfixes and long term stability. I wouldn't say that it is done, but 2.0.5 will represent the next stable release. I was talking with some of the developers at ApacheCon last year, and there are some ways that we may explore to make mod_perl more modular and easier to use. If you need the latest and greatest, you can always pull from subversion. The trunk is very stable right now and contains some fixes that will be released with 2.0.5. I've been working on Apache::Bootstrap to minimize the pain of releasing updates to the Apache::* modules, and can always use help testing there. Also, there are usually active mod_perl developers on the #modperl irc channel at irc.perl.org, feel free to drop in and say hi! > > It does exactly what it needs to do, so changes are only required when > the apache interface changes or a bug is discovered. > > I've been using mod_perl on linux for the past 13 years, and the only > time I've experienced segfaults was when I was trying to open a database > handle in the parent process and use it in the children. > > mod_perl is used by a LOT of big companies, and they wouldn't use it if > it weren't stable and reliable. > > You almost undoubtedly have a problem in your code - at first guess, I'd > look for any code that is trying to share file handles or pipes between > children. > > And follow Adam's advice: > > >> >> Have you read this section of the docmentation on perl.apache.org? >> http://perl.apache.org/docs/2.0/devel/debug/c.html >> particularly the stuff about generating core dumps and analyzing them >> > regards > > Clint > > >
Re: Is mod_perl dead?
On Mon, Aug 10, 2009 at 8:09 AM, Igor Chudov wrote: > Thanks, guys. I think that I found the issue, a C compiled executable that > would crash after doing its job. I fixed it and it no longer crashes. No > more segfaults for me. Thanks a lot to all, and I am glad to hear that > mod_perl is a well supported project. One think to consider also is that most of the development resources are going towards stability. mod_perl will be here in 5,10,15, probably 20 years. It's already been around for 10. I talked to Paul Querna at OSCON (one of the Apache httpd developers), and mod_perl will function with the next version of Apache, which will be 2.4. There are probably other httpd developers on this list, so please chime in with your thoughts there. If you look at other open source projects which are very active, most of that activity is going towards new untested development. Not the code that you can run your huge website on and expect high stability and scalability. > > Igor > > On Mon, Aug 10, 2009 at 9:17 AM, Alan McKay wrote: >> >> Igor, >> >> Are you familiar with how to prepare mod_perl for a proper core dump, >> and then load the core dump into the debugger? >> >> I fought through this not long ago - though was not that difficult. >> >> http://httpd.apache.org/dev/debugging.html >> >> http://perl.apache.org/docs/2.0/devel/debug/c.html#Analyzing_Dumped_Core_Files >> >> Of course, that ended up getting me nowhere. Here is another >> technique that may help you : >> >> >> http://modperlbook.org/html/21-5-8-Noninteractive-Perl-Debugging-Under-mod_perl.html >> >> cheers, >> -Alan >> >> >> -- >> “Don't eat anything you've ever seen advertised on TV” >> - Michael Pollan, author of "In Defense of Food" > >
Re: Apache2::Reload
That's the correct address; I didn't see an email there though. Suggest you repost your email to d...@perl.apache.org with the patch inline in the email. You need to be subscribed to d...@perl.apache.org to post there. On Tue, Aug 18, 2009 at 5:51 AM, Ryan Gies wrote: > Howdy, as I have not received a response from dev at perl.apache.org I'm > thinking that was not the correct recipient. I just have a patch for > Apache2::Reload and want to know where to send it... > > Cheers, > -Ryan > > Original Message > Subject: Apache2::Reload > Date: Wed, 12 Aug 2009 11:32:21 -0400 > From: Ryan Gies > Organization: Livesite Netwoks, LLC > To: d...@perl.apache.org > > > I have a patch for Apache2::Reload which does two things: > > a) ignores require-hooks which exist in %INC (fix) > b) reloads by file, not module name (fix?) > > I consider both of these fixes, however b) is a behavior change and > would like to discuss this with someone before finishing the doc > comments and sending upstream. > > Am I writing to the correct group and does anyone have want to take > this on (I expect it to be quick)? > > Cheers, > -Ryan > >
Re: unreadable output after internal redirect
On Thu, Aug 20, 2009 at 7:54 AM, Mark Copper wrote:
> Hi,
>
> I have a Mason dhandler that generates an HTML page containing a form.
> The action of the form is to get the same page that is displayed. If the
> URL contains a certain parameter, an internal redirect is issued:
Can you provide what versions of mod_perl, apache, and perl you are using?
Have you asked the Mason list also? Is there a reason why you aren't
using an external redirect here? Seems like you might want that
instead of the internal_redirect, since you are redirecting to a
different url.
>
> URL: mydomain.com/information/dhandler/variable.html?modification=update
>
> <%args>
> $modification=>undef
>
>
> ...
>
> ...
>
> ...
>
>
>
> ...
> if ($modification eq "update"){
> my $location = "/data_update?session=$session&" . $r->args;
> $r->internal_redirect($location);
> return OK;
> ...
>
>
> A Perl handler processes requests to /data_update and issues a new
> internal redirect to a third page:
>
>
> SetHandler perl-script
> PerlHandler MyApp::DataUpdate
> DefaultType text/html
>
>
> The third page (usually) displays correctly but there is trouble
> beneath. Following any link on the third page results in a display of
> gibberish--binary data except for the HTTP header buried midway through.
> This third page never causes any trouble except when approached through
> this internal redirect.
>
>
> I've probably left out all the information you need to know in order to
> suggest a solution. So I guess that's my question; where do I need to
> look more carefully?
>
> Sorry if *this* page is gibberish. Thanks for reading.
>
> Mark
>
Re: At random moments, mod_perl starts returning empty pages
On Tue, Aug 25, 2009 at 8:09 AM, Igor Chudov wrote: > My website algebra.com has been moved to a new server running Ubuntu Hardy. > > While everything seems to be working well, esp. the kernel and solid state > disk, I have one issue. > > The issue is that at random moments, usually once or twice a day, my > webserver starts returning completely empty pages instead of actual content. > The pages are mod_perl based. > > I tried restarting apache every 30 minutes, but it does not help. It appears > to be a random issue as opposed to a "server getting tired" issue. > > I have a cron job that checks my webserver every 5 minutes and restarts it > when necessary, but obviously I hate the situation and would like to fix it. > > Any pointers to get started would be appreciated. Please post your version details, and the relevant sections of httpd.conf. Have you witnessed this? Are you able to get any server response headers?
Re: At random moments, mod_perl starts returning empty pages
One great tool that would help with the diagnosis is the very useful mp2bug, found in mod_perl-2.0/bin/mp2bug Can you run that from your mod_perl install and post the output? Version details are a huge clue in solving mysteries like this. On Tue, Aug 25, 2009 at 10:10 AM, Igor Chudov wrote: > > > On Tue, Aug 25, 2009 at 10:50 AM, Frank Wiles wrote: >> >> >> > I am afraid that it is hard to reproduce. Since I run ads and such, I >> > cannot >> > really afford to pause for very long to debug the issue, plus it happens >> > randomly. My 5 minute restarter saves me from a very big trouble >> >> No of course, that's why I suggested running it on a higher port and >> leaving your production site alone. Just to isolate the problem down >> as small as possible. (i.e. no perlbal, single apache process, no >> other users, etc. ) to see if you can narrow down what piece of the >> puzzle is the one causing the issue. >> >> Frank, I tried to run apache2 -X and did thousands of queries, they did >> not break anything. It is "something else". > > Re: segfaults: I do get segfaults in apache, indeed. > > Re: httpd config file: See attached. It is kind of big. >
Re: At random moments, mod_perl starts returning empty pages
On Tue, Aug 25, 2009 at 12:05 PM, Igor Chudov wrote: > > > On Tue, Aug 25, 2009 at 12:16 PM, Fred Moyer wrote: >> >> One great tool that would help with the diagnosis is the very useful >> mp2bug, found in mod_perl-2.0/bin/mp2bug >> >> Can you run that from your mod_perl install and post the output? >> Version details are a huge clue in solving mysteries like this. >> > > Fred, thanks. here goes. > > > -8<-- Start Bug Report 8<-- > 1. Problem Description: > > [DESCRIBE THE PROBLEM HERE] > > 2. Used Components and their Configuration: > > *** mod_perl version 2.03 Suggest trying 2.0.4. If that still exhibits the problem, suggest pulling a copy of subversion trunk and trying that. I'm currently running trunk on my servers (very stable). > > *** using /usr/lib/perl5/Apache2/BuildConfig.pm > > *** Makefile.PL options: > MP_APR_LIB => aprext > MP_APXS => /usr/bin/apxs2 > MP_CCOPTS => -g -Wall > MP_COMPAT_1X => 1 > MP_GENERATE_XS => 1 > MP_INCLUDE_DIR => /usr/include/apache2 /usr/include/apr-1.0 > MP_LIBNAME => mod_perl > MP_TRACE => 0 > MP_USE_DSO => 1 > MP_USE_GTOP => 1 > MP_USE_STATIC => 0 > > > *** The httpd binary was not found > > > *** (apr|apu)-config linking info > > (apr|apu)-config scripts were not found > > > > *** /usr/bin/perl -V > Summary of my perl5 (revision 5 version 8 subversion 8) configuration: > Platform: > osname=linux, osvers=2.6.24-19-server, > archname=i486-linux-gnu-thread-multi > uname='linux palmer 2.6.24-19-server #1 smp sat jul 12 00:40:01 utc 2008 > i686 gnulinux ' > config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN > -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr > -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 > -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 > -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.8 > -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 > -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 > -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl > -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm > -Duseshrplib -Dlibperl=libperl.so.5.8.8 -Dd_dosuid -des' > hint=recommended, useposix=true, d_sigaction=define > usethreads=define use5005threads=undef useithreads=define > usemultiplicity=define > useperlio=define d_sfio=undef uselargefiles=define usesocks=undef > use64bitint=undef use64bitall=undef uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS > -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64', > optimize='-O2', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN > -fno-strict-aliasing -pipe -I/usr/local/include' > ccversion='', gccversion='4.2.3 (Ubuntu 4.2.3-2ubuntu7)', > gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=4, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt > perllibs=-ldl -lm -lpthread -lc -lcrypt > libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8 > gnulibc_version='2.7' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' > cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT > PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS > USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API > Built under linux > Compiled at Jan 14 2009 22:34:36 > %ENV: > > PERL5LIB="/home/ichudov/misc/life/modules:/home/ichudov/lisleelectric.com" > > PERLLIB="/home/ichudov/misc/life/modules:/home/ichudov/lisleelectric.com" > PERL_LWP_USE_HTTP_10="1" > @INC: > /home/ichudov/misc/life/modules > /home/ichudov
Re: At random moments, mod_perl starts returning empty pages
Igor, Please cc the mod_perl list on all replies. I'm available for professional mod_perl consulting offlist, but I don't come cheap :) On Tue, Aug 25, 2009 at 12:14 PM, Igor Chudov wrote: > > > On Tue, Aug 25, 2009 at 2:07 PM, Fred Moyer wrote: >> >> > *** mod_perl version 2.03 >> >> Suggest trying 2.0.4. If that still exhibits the problem, suggest >> pulling a copy of subversion trunk and trying that. I'm currently >> running trunk on my servers (very stable). > > Fred, I have not compiled mod_perl in ~4 years. > > What is the process here, do I just download tarball and do configure and > install? Is it any trickier? http://perl.apache.org/docs/2.0/user/intro/start_fast.html > The risks involved are kind of big here. So I want to be safe and have a > good plan. Suggest building this side by side with your existing installation. Suggest testing this out first on your test environment.
Re: At random moments, mod_perl starts returning empty pages
On Tue, Aug 25, 2009 at 1:07 PM, Igor Chudov wrote: >> > The risks involved are kind of big here. So I want to be safe and have a >> > good plan. >> >> Suggest building this side by side with your existing installation. >> Suggest testing this out first on your test environment. > > OK, I did build it, it was nice. > > My plan is to: > > 1) Remove ubuntu mod_perl package > 2) Do make install > 3) test > > If test succeeds, I will stop. If test fails, I would reinstall the system > mod_perl. > > Is that a safe plan? I'd try this on a test server first (which ideally is a replicate of your production environment. Best thing to do is have a rollback plan IMHO.
Re: News regarding mod_perl returning empty pages
On Tue, Aug 25, 2009 at 7:20 PM, Igor Chudov wrote: > My new perlbal.conf is included: > > REATE POOL dynamic > pool dynamic add 127.0.0.1:10080 > > CREATE SERVICE balancer > SET listen = 0.0.0.0:80 > SET role = reverse_proxy > SET pool = dynamic > SET persist_client = on > SET persist_backend = off > SET verify_backend = on With verify_backend = on, perlbal makes an OPTIONS request to the mod_perl server. That request usually returns an empty 200, which in other scenarios could be viewed as a blank page. How perlbal would send that back to the client is something I don't know. But I would consider disabling that option as it doubles the number of total requests to the backend mod_perl server. That's just my opinion though, changing that failure could cause other failure modes to surface. If you want to use that option, you should write a mod_perl handler that answers to a verify_backend url (see the perlbal docs) and returns a few characters of text back to perlbal. If you see those characters in your blank screens - that's the problem. Although I'm skeptical that is what is happening.
Re: News regarding mod_perl returning empty pages
On Wed, Aug 26, 2009 at 8:16 AM, Perrin Harkins wrote: > On Wed, Aug 26, 2009 at 11:12 AM, Igor Chudov wrote: >> Do you refer to the response size, as opposed to request size? > > Yes. > >> If so... I like your idea. How would I do that? > > Just read the logging section of the apache docs. It's a common part > of the access log. This is a good reference: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
Re: mod_perl 2.0.5 ETA?
On Wed, Aug 26, 2009 at 10:44 AM, wrote: > So Perl 5.10.1 is out, and my Apache is a couple of releases old, and the > latest mod_apreq2 failed testing from source so I can try it from the > FreeBSD ports. Which is close to critical mass to rebuild my site software. > > Does anyone reading this know the state of the next mod_perl2? There's a few issues that need to be resolved with the external modules such as Apache::Reload. A lot of discussion occurred on the dev list regarding the best practice for bundling these modules with mod_perl2 core vs. making them separately available. I need to look through the archives to verify, but I think a consensus was reached to ship Apache2?::* modules bundled with core, but also allow for separate module releases as needed. Other than those bundling issues, svn tip is in great shape. I've got it running in production and it just works. > Like when it might be released? My guess would be when it is ready. The best way to make that happen is to test with svn trunk, and report back success or failures to the list. The issues that are in the front of the minds of the developers are usually stability, scalability, and maintainability. Releasing a numbered version of mod_perl takes a lot of work. There's prefork, win32, mpm-worker variants that must be tested on variants of perl/apache/libapreq/os. How can you help make it happen? By posting this email you have already taken the first step. Go ahead and download 5.10.1 and test it out with your setup and mod_perl svn trunk, and report back with success or failure. Success cases are usually boring, but failures are interesting and present problems that need to be solved.
Re: Undefined symbol "Perl_pad_sv building mp2
On Sat, Aug 29, 2009 at 9:43 PM, wrote: > -8<-- Start Bug Report 8<-- > 1. Problem Description: > > I have upgraded to Apache 2.2.13 and Perl 5.10.1. Both seem to be working > OK, > although Apache with using my old mod_perl 2.04 that uses perl 5.8.9. Have you rebuilt your mod_perl 2.0.4 instance from scratch using 5.10.1? Undefined symbol warnings like this usually mean you are trying to use a version of mod_perl that has been built with another perl binary. Suggest running make clean, then: perl Makefile.PL MP_APXS=/path/to/my/httpd/apxs make make test > > make test in both the release mod_perl 2.0.4 and the latest snapshot 2.0.5 > gives the same error: > > $ make test > cd "src/modules/perl" && make > /usr/bin/perl -Iblib/arch -Iblib/lib t/TEST -clean > APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= > APACHE_TEST_APXS= /usr/bin/perl -Iblib/arch -Iblib/lib t/TEST -bugreport > -verbose=0 > /usr/local/apache2/bin/httpd -d /build/modperl-2.0/t -f > /build/modperl-2.0/t/conf/httpd.conf -D APACHE2 > using Apache/2.2.13 (prefork MPM) > > waiting 120 seconds for server to start: .httpd: Syntax error on line 17 of > /build/modperl-2.0/t/conf/httpd.conf: Cannot load > /build/modperl-2.0/src/modules/perl/mod_perl.so into server: > /build/modperl-2.0/src/modules/perl/mod_perl.so: Undefined symbol > "Perl_pad_sv" > > > 2. Used Components and their Configuration: > > *** mod_perl version 2.05 > > *** using /build/modperl-2.0/lib/Apache2/BuildConfig.pm > > *** Makefile.PL options: > MP_APR_LIB => aprext > MP_APXS => /usr/local/apache2/bin/apxs > MP_COMPAT_1X => 1 > MP_GENERATE_XS => 1 > MP_LIBNAME => mod_perl > MP_USE_DSO => 1 > > > *** /usr/local/apache2/bin/httpd -V > Server version: Apache/2.2.13 (Unix) > Server built: Aug 29 2009 16:57:40 > Server's Module Magic Number: 20051115:23 > Server loaded: APR 1.3.8, APR-Util 1.3.9 > Compiled using: APR 1.3.8, APR-Util 1.3.9 > Architecture: 32-bit > Server MPM: Prefork > threaded: no > forked: yes (variable process count) > Server compiled with > -D APACHE_MPM_DIR="server/mpm/prefork" > -D APR_HAS_SENDFILE > -D APR_HAS_MMAP > -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) > -D APR_USE_FLOCK_SERIALIZE > -D APR_USE_PTHREAD_SERIALIZE > -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT > -D APR_HAS_OTHER_CHILD > -D AP_HAVE_RELIABLE_PIPED_LOGS > -D DYNAMIC_MODULE_LIMIT=128 > -D HTTPD_ROOT="/usr/local/apache2" > -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" > -D DEFAULT_PIDLOG="logs/httpd.pid" > -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" > -D DEFAULT_LOCKFILE="logs/accept.lock" > -D DEFAULT_ERRORLOG="logs/error_log" > -D AP_TYPES_CONFIG_FILE="conf/mime.types" > -D SERVER_CONFIG_FILE="conf/httpd.conf" > > *** /usr/bin/ldd /usr/local/apache2/bin/httpd > /usr/local/apache2/bin/httpd: > libz.so.3 => /lib/libz.so.3 (0x28209000) > libm.so.4 => /lib/libm.so.4 (0x2821a000) > libpcre.so.0 => /usr/local/lib/libpcre.so.0 (0x2823) > libaprutil-1.so.3 => /usr/local/apache2/lib/libaprutil-1.so.3 > (0x2825c000) > libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x2827c000) > libapr-1.so.3 => /usr/local/apache2/lib/libapr-1.so.3 (0x2829d000) > libcrypt.so.3 => /lib/libcrypt.so.3 (0x282c5000) > libpthread.so.2 => /lib/libpthread.so.2 (0x282dd000) > libc.so.6 => /lib/libc.so.6 (0x28301000) > > > *** (apr|apu)-config linking info > > -L/usr/local/apache2/lib -laprutil-1 -lexpat -L/usr/local/lib > -L/usr/local/apache2/lib -lapr-1 -lcrypt -lpthread > > > > *** /usr/local/bin/perl -V > Summary of my perl5 (revision 5 version 10 subversion 1) configuration: > > Platform: > osname=freebsd, osvers=6.3-release, archname=i386-freebsd > uname='freebsd animalhead.com 6.3-release freebsd 6.3-release #3: fri jan > 23 16:43:41 mst 2009 r...@fc:usrsrcsysi386compilevkern i386 ' > config_args='-Dd_dosuid > -Dotherlibdirs=/usr/local/lib/perl5/5.8.9:/usr/local/lib/perl5/5.8.8:/usr/local/lib/perl5/5.8.7 > -Dvendorprefix=/usr/local -Dmydomain=animalhead.com' > hint=recommended, useposix=true, d_sigaction=define > useithreads=undef, usemultiplicity=undef > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=undef, use64bitall=undef, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H > -fno-strict-aliasing -pipe -I/usr/local/include', > optimize='-O', > cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing > -pipe -I/usr/local/include' > ccversion='', gccversion='3.4.6 [FreeBSD] 20060305', gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes
Re: Undefined symbol "Perl_pad_sv" building mp2
On Tue, Sep 1, 2009 at 9:27 AM, wrote: > A bit more data on the problem reported below: > > /build/modperl-2.0 $ grep -r Perl_pad_sv * > Binary file src/modules/perl/mod_perl.so matches > /build/modperl-2.0 $ ll src/modules/perl/mod_perl.so > -rwxr-xr-x 1 user wheel 1559168 Aug 29 21:22 src/modules/perl/mod_perl.so > /build/modperl-2.0 $ cd /usr/local/bin > > /usr/local/bin $ ll perl5* > lrwxr-xr-x 1 root wheel 10 Aug 29 16:04 perl5 -> perl5.10.1 > -rwxr-xr-x 3 root wheel 1078522 Aug 30 00:52 perl5.10.1 > -rwxr-xr-x 2 root wheel 949166 Nov 14 2005 perl5.8.7 > -rwxr-xr-x 1 root wheel 2050866 Nov 18 2008 perl5.8.8 > -rwxr-xr-x 1 root wheel 951373 Jan 7 2009 perl5.8.9 > /usr/local/bin $ grep -r Perl_pad_sv perl* > Binary file perl5.8.7 matches > Binary file perl5.8.8 matches > Binary file perl5.8.9 matches > /usr/local/bin $ > > So the symbol in the error message is wanted by the newly-built > mod_perl, but perl 5.10.1 does not include it. > > Yes that's exactly what the error message says, but the mailing > list is so quiet that I wonder if my filters have started eating > its emails... Perl_pad_sv is in there. How did you install 5.10.1? ph...@harpua ~/perl-5.10.1 $ ack Perl_pad_sv embed.h 638:#define pad_sv Perl_pad_sv 2958:#define pad_sv(a) Perl_pad_sv(aTHX_ a) makedef.pl 627:Perl_pad_sv pad.c 927:Perl_pad_sv(pTHX_ PADOFFSET po) proto.h 2386:PERL_CALLCONV SV* Perl_pad_sv(pTHX_ PADOFFSET po); > > cmac > >> On Aug 30, 2009, at 11:49 AM, Fred Moyer wrote: >> >>> On Sat, Aug 29, 2009 at 9:43 PM, wrote: >>>> >>>> -8<-- Start Bug Report 8<-- >>>> 1. Problem Description: >>>> >>>> I have upgraded to Apache 2.2.13 and Perl 5.10.1. Both seem to be >>>> working >>>> OK, >>>> although Apache with using my old mod_perl 2.04 that uses perl 5.8.9. >>> >>> Have you rebuilt your mod_perl 2.0.4 instance from scratch using >>> 5.10.1? Undefined symbol warnings like this usually mean you are >>> trying to use a version of mod_perl that has been built with another >>> perl binary. >>> >>> Suggest running make clean, then: >>> >>> perl Makefile.PL MP_APXS=/path/to/my/httpd/apxs >>> make >>> make test >> >> Yes, that is pretty much exactly what I've done. Here is the command file >> (that precedes make): >> >> #! /bin/sh >> CFLAGS="-DVERIO -DVERIO_VPS"; export CFLAGS >> LDFLAGS="-L/usr/local/lib"; export LDFLAGS >> perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs >> >>>> >>>> make test in both the release mod_perl 2.0.4 and the latest snapshot >>>> 2.0.5 >>>> gives the same error: >>>> >>>> $ make test >>>> cd "src/modules/perl" && make >>>> /usr/bin/perl -Iblib/arch -Iblib/lib t/TEST -clean >>>> APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= >>>> APACHE_TEST_USER= >>>> APACHE_TEST_APXS= /usr/bin/perl -Iblib/arch -Iblib/lib t/TEST >>>> -bugreport >>>> -verbose=0 >>>> /usr/local/apache2/bin/httpd -d /build/modperl-2.0/t -f >>>> /build/modperl-2.0/t/conf/httpd.conf -D APACHE2 >>>> using Apache/2.2.13 (prefork MPM) >>>> >>>> waiting 120 seconds for server to start: .httpd: Syntax error on line 17 >>>> of >>>> /build/modperl-2.0/t/conf/httpd.conf: Cannot load >>>> /build/modperl-2.0/src/modules/perl/mod_perl.so into server: >>>> /build/modperl-2.0/src/modules/perl/mod_perl.so: Undefined symbol >>>> "Perl_pad_sv" >>>> >>>> >>>> 2. Used Components and their Configuration: >>>> >>>> *** mod_perl version 2.05 >>>> >>>> *** using /build/modperl-2.0/lib/Apache2/BuildConfig.pm >>>> >>>> *** Makefile.PL options: >>>> MP_APR_LIB => aprext >>>> MP_APXS => /usr/local/apache2/bin/apxs >>>> MP_COMPAT_1X => 1 >>>> MP_GENERATE_XS => 1 >>>> MP_LIBNAME => mod_perl >>>> MP_USE_DSO => 1 >>>> >>>> >>>> *** /usr/local/apache2/bin/httpd -V >>>> Server version: Apache/2.2.13 (Unix) >>>> Server built: Aug 29 2009 16:57:40 >>>> Server's Module Magic Number: 20051115:23 >>>> Server loaded: APR 1.3.8, APR-Util 1
Re: Undefined symbol "Perl_pad_sv" building mp2
Can you please cc the list on all replies? On Tue, Sep 1, 2009 at 5:41 PM, wrote: > cd /build/perl-5.10.1/ > make veryclean > ./Configure -Dd_dosuid > -Dotherlibdirs=/usr/local/lib/perl5/5.8.9:/usr/local/lib/perl5/site_perl/5.8.9:/usr/local/lib/perl5/5.8.8:/usr/local/lib/perl5/site_perl/5.8.8:/usr/local/lib/perl5/5.8.7:/usr/local/lib/perl5/site_perl/5.8.7:/usr/local/lib/perl5/vendor_perl/5.8.7 > -Dmydomain=animalhead.com Why are you configuring 5.10.1 with 5.8.x libs? Can you try a build without otherlibdirs? > > change optimization '-O' to '-O2' > search other versions? [5.8.9 5.8.8 5.8.7] none > change email 'x...@animalhead.com' to 'macke...@...' > > make > make test <-- no errors for 5.10.1 > sudo make install > > > On Sep 1, 2009, at 11:23 AM, Fred Moyer wrote: > >> On Tue, Sep 1, 2009 at 9:27 AM, wrote: >>> >>> A bit more data on the problem reported below: >>> >>> /build/modperl-2.0 $ grep -r Perl_pad_sv * >>> Binary file src/modules/perl/mod_perl.so matches >>> /build/modperl-2.0 $ ll src/modules/perl/mod_perl.so >>> -rwxr-xr-x 1 user wheel 1559168 Aug 29 21:22 >>> src/modules/perl/mod_perl.so >>> /build/modperl-2.0 $ cd /usr/local/bin >>> >>> /usr/local/bin $ ll perl5* >>> lrwxr-xr-x 1 root wheel 10 Aug 29 16:04 perl5 -> perl5.10.1 >>> -rwxr-xr-x 3 root wheel 1078522 Aug 30 00:52 perl5.10.1 >>> -rwxr-xr-x 2 root wheel 949166 Nov 14 2005 perl5.8.7 >>> -rwxr-xr-x 1 root wheel 2050866 Nov 18 2008 perl5.8.8 >>> -rwxr-xr-x 1 root wheel 951373 Jan 7 2009 perl5.8.9 >>> /usr/local/bin $ grep -r Perl_pad_sv perl* >>> Binary file perl5.8.7 matches >>> Binary file perl5.8.8 matches >>> Binary file perl5.8.9 matches >>> /usr/local/bin $ >>> >>> So the symbol in the error message is wanted by the newly-built >>> mod_perl, but perl 5.10.1 does not include it. >>> >>> Yes that's exactly what the error message says, but the mailing >>> list is so quiet that I wonder if my filters have started eating >>> its emails... >> >> Perl_pad_sv is in there. How did you install 5.10.1? >> >> ph...@harpua ~/perl-5.10.1 $ ack Perl_pad_sv >> embed.h >> 638:#define pad_sv Perl_pad_sv >> 2958:#define pad_sv(a) Perl_pad_sv(aTHX_ a) >> >> makedef.pl >> 627: Perl_pad_sv >> >> pad.c >> 927:Perl_pad_sv(pTHX_ PADOFFSET po) >> >> proto.h >> 2386:PERL_CALLCONV SV* Perl_pad_sv(pTHX_ PADOFFSET po); >> >> >>> >>> cmac >>> >>>> On Aug 30, 2009, at 11:49 AM, Fred Moyer wrote: >>>> >>>>> On Sat, Aug 29, 2009 at 9:43 PM, wrote: >>>>>> >>>>>> -8<-- Start Bug Report 8<-- >>>>>> 1. Problem Description: >>>>>> >>>>>> I have upgraded to Apache 2.2.13 and Perl 5.10.1. Both seem to be >>>>>> working >>>>>> OK, >>>>>> although Apache with using my old mod_perl 2.04 that uses perl 5.8.9. >>>>> >>>>> Have you rebuilt your mod_perl 2.0.4 instance from scratch using >>>>> 5.10.1? Undefined symbol warnings like this usually mean you are >>>>> trying to use a version of mod_perl that has been built with another >>>>> perl binary. >>>>> >>>>> Suggest running make clean, then: >>>>> >>>>> perl Makefile.PL MP_APXS=/path/to/my/httpd/apxs >>>>> make >>>>> make test >>>> >>>> Yes, that is pretty much exactly what I've done. Here is the command >>>> file >>>> (that precedes make): >>>> >>>> #! /bin/sh >>>> CFLAGS="-DVERIO -DVERIO_VPS"; export CFLAGS >>>> LDFLAGS="-L/usr/local/lib"; export LDFLAGS >>>> perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs >>>> >>>>>> >>>>>> make test in both the release mod_perl 2.0.4 and the latest snapshot >>>>>> 2.0.5 >>>>>> gives the same error: >>>>>> >>>>>> $ make test >>>>>> cd "src/modules/perl" && make >>>>>> /usr/bin/perl -Iblib/arch -Iblib/lib t/TEST -clean >>>>>> APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APA
Re: Undefined symbol "Perl_pad_sv" building mp2
[cc'ing the list as to not break the thread] On Tue, Sep 1, 2009 at 7:41 PM, wrote: > I have always included previous perl libraries in the @INC of > new builds. And it has always worked, with the single > exception of building mod_perl2 this time. All of the perl > scripts and modules on my site work well under the new 5.10.1. I don't know enough here to say one way or the other about this, but you're mixing major versions of perl (5.10 vs 5.8) The Perl 5 Porters would be a good place for these issues. But you are seeing unresolved symbol errors when trying to use different major versions of Perl. That is enough circumstantial evidence that if I were in your shoes, I'd use a separate 5.10 install. But p5p could probably give a more educated analysis of this. > > Aside from the pain of re-downloading all kinds of modules > as they prove to be needed over the next year or so, I know > there are items in the 5.8.7 libraries from my Internet > Hosting Provider, that are needed to run software from the IHP. > > I can certainly build a 5.10.1 without the otherlibs, and > locate it somewhere else than in /usr/local/bin. Will that > process completely replace all of: > > /usr/local/lib/perl5/5.10.1/i386-freebsd > /usr/local/lib/perl5/5.10.1 > /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd > /usr/local/lib/perl5/site_perl/5.10.1 > ?? > > If so, I suppose could copy them somewhere before the > build, and copy them back after the build. > > In "Non-Boolean Build Options" on > > http://perl.apache.org/docs/2.0/user/install/install.html, > > I don't see a command to tell the mod_perl build process to > use a particular perl. If I say $perl_other Makefile.PL > in the modperl-2.x directory, does that do it? > > Thanks for being there, > cmac > > > On Sep 1, 2009, at 5:58 PM, Fred Moyer wrote: > >> Can you please cc the list on all replies? >> >> On Tue, Sep 1, 2009 at 5:41 PM, wrote: >>> >>> cd /build/perl-5.10.1/ >>> make veryclean >>> ./Configure -Dd_dosuid >>> >>> -Dotherlibdirs=/usr/local/lib/perl5/5.8.9:/usr/local/lib/perl5/site_perl/5.8.9:/usr/local/lib/perl5/5.8.8:/usr/local/lib/perl5/site_perl/5.8.8:/usr/local/lib/perl5/5.8.7:/usr/local/lib/perl5/site_perl/5.8.7:/usr/local/lib/perl5/vendor_perl/5.8.7 >>> -Dmydomain=animalhead.com >> >> Why are you configuring 5.10.1 with 5.8.x libs? >> >> Can you try a build without otherlibdirs? >> >>> >>> change optimization '-O' to '-O2' >>> search other versions? [5.8.9 5.8.8 5.8.7] none >>> change email 'x...@animalhead.com' to 'macke...@...' >>> >>> make >>> make test <-- no errors for 5.10.1 >>> sudo make install >>> >>> >>> On Sep 1, 2009, at 11:23 AM, Fred Moyer wrote: >>> >>>> On Tue, Sep 1, 2009 at 9:27 AM, wrote: >>>>> >>>>> A bit more data on the problem reported below: >>>>> >>>>> /build/modperl-2.0 $ grep -r Perl_pad_sv * >>>>> Binary file src/modules/perl/mod_perl.so matches >>>>> /build/modperl-2.0 $ ll src/modules/perl/mod_perl.so >>>>> -rwxr-xr-x 1 user wheel 1559168 Aug 29 21:22 >>>>> src/modules/perl/mod_perl.so >>>>> /build/modperl-2.0 $ cd /usr/local/bin >>>>> >>>>> /usr/local/bin $ ll perl5* >>>>> lrwxr-xr-x 1 root wheel 10 Aug 29 16:04 perl5 -> perl5.10.1 >>>>> -rwxr-xr-x 3 root wheel 1078522 Aug 30 00:52 perl5.10.1 >>>>> -rwxr-xr-x 2 root wheel 949166 Nov 14 2005 perl5.8.7 >>>>> -rwxr-xr-x 1 root wheel 2050866 Nov 18 2008 perl5.8.8 >>>>> -rwxr-xr-x 1 root wheel 951373 Jan 7 2009 perl5.8.9 >>>>> /usr/local/bin $ grep -r Perl_pad_sv perl* >>>>> Binary file perl5.8.7 matches >>>>> Binary file perl5.8.8 matches >>>>> Binary file perl5.8.9 matches >>>>> /usr/local/bin $ >>>>> >>>>> So the symbol in the error message is wanted by the newly-built >>>>> mod_perl, but perl 5.10.1 does not include it. >>>>> >>>>> Yes that's exactly what the error message says, but the mailing >>>>> list is so quiet that I wonder if my filters have started eating >>>>> its emails... >>>> >>>> Perl_pad_sv is in there. How did you install 5.10.1? >>>> >>>> ph...@harpua ~/perl-5.10.1 $ ack Perl_pad_sv >>>> embe
Re: Undefined symbol "Perl_pad_sv" building mp2
On Tue, Sep 1, 2009 at 10:14 PM, wrote: > But this is the mod_perl mailing list. It is the place to which > one sends reports of bugs or problems with mod_perl. I sent such > a report, citing this undefined symbol when building mod_perl2. Right, but if you are mixing major versions of perl, you'll probably encounter issues in other places. mod_perl may be the first place you are seeing this. Think of it this way - would you try this same install procedure with 5.6 and 5.8? Maybe 5.8 and 5.10 work together seamlessly, but I would look to that as a likely source of problems. ack is App::Ack, available from CPAN. I've pulled down 5.10.1 but haven't had time to do a build yet. When I do, I'm going to install 5.10.1 a separate location from my 5.8 libraries. Maybe it can integrate with 5.8 (the perl 5 porters are a very talented crew), but discovering an edge case is not something on my todo list :) I like to keep my mod_perl setup using a different perl build than the system perl. That way, I won't hose my system if I want to try some new build options for my mod_perl based perl install. > It is hard for me to imagine that the fact that I gave the perl > build process a list of directories to append to @INC should > affect the presence or absence of a symbol in the resultant perl > binary. The only time that perl will even consult those > directories are when it is looking for a module name that it > doesn't find in the 5.10.1 directories. > > There is not much in the modules in @INC directories that is > necessarily connected to "major versions of perl". Of course > it's possible that some older modules may not work as well with > a new version as with older versions, but in this case it's the > responsibility of the author to work out and release a new > version that will hopefully work equally well with the older > and newer perls. And any module can specify the oldest version > of perl (or other modules on which it depends) that it will > work with. > > I always maintain my perl modules with -MCPAN's r command, and > upgrade those for which new versions are available on a regular > basis. > > I don't know the command 'ack' that you used in your work below, > but it looks like it examined source files in a subdirectory of > your home directory (~). > > Do you have a perl5.10.1 binary that you have used in conjunction > with mod_perl2? > > If so, can you please cd to the directory that contains that > binary (/usr/local/bin?) and enter a grep command like I used: > > grep Perl_pad_sv perl5* > > and see if your 5.10.1 binary contains the symbol? And if so, > how did your binary come to be? > > Thanks, > cmac > > > On Sep 1, 2009, at 9:32 PM, Fred Moyer wrote: > >> [cc'ing the list as to not break the thread] >> >> On Tue, Sep 1, 2009 at 7:41 PM, wrote: >>> >>> I have always included previous perl libraries in the @INC of >>> new builds. And it has always worked, with the single >>> exception of building mod_perl2 this time. All of the perl >>> scripts and modules on my site work well under the new 5.10.1. >> >> I don't know enough here to say one way or the other about this, but >> you're mixing major versions of perl (5.10 vs 5.8) >> >> The Perl 5 Porters would be a good place for these issues. But you >> are seeing unresolved symbol errors when trying to use different major >> versions of Perl. That is enough circumstantial evidence that if I >> were in your shoes, I'd use a separate 5.10 install. But p5p could >> probably give a more educated analysis of this. >> >>> >>> Aside from the pain of re-downloading all kinds of modules >>> as they prove to be needed over the next year or so, I know >>> there are items in the 5.8.7 libraries from my Internet >>> Hosting Provider, that are needed to run software from the IHP. >>> >>> I can certainly build a 5.10.1 without the otherlibs, and >>> locate it somewhere else than in /usr/local/bin. Will that >>> process completely replace all of: >>> >>> /usr/local/lib/perl5/5.10.1/i386-freebsd >>> /usr/local/lib/perl5/5.10.1 >>> /usr/local/lib/perl5/site_perl/5.10.1/i386-freebsd >>> /usr/local/lib/perl5/site_perl/5.10.1 >>> ?? >>> >>> If so, I suppose could copy them somewhere before the >>> build, and copy them back after the build. >>> >>> In "Non-Boolean Build Options" on >>> >>> http://perl.apache.org/docs/2.0/user/install/install.html, >>> >>> I don't see a command t
Re: a better way to recognize module changes
On Fri, Sep 11, 2009 at 3:02 PM, Devin Teske wrote: > Maybe somebody can refute what I'm seeing, but as of mod_perl-2.0.4, > Apache2::Reload is gone (so you can remove that from your list of > options). It was not bundled with 2.0.4 but is available on CPAN: http://search.cpan.org/dist/Apache-Reload It will be bundled again with 2.0.5. There was a discussion on the dev list about how to manage perl based Apache2?::* modules with mod_perl core releases and the specific version control procedures to accomplish this in a pain free manner. > -- > Devin > > On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote: >> I'm thinking about an improved solution to recognizing module changes >> in a running server, without restarting the server. >> >> These are the solutions I know about: >> >> 1) Apache2::Reload / Module::Reload >> >> These check whether modules have changed on each request, and if so, >> clear their symbols and reload them inside the process. >> >> Problem: some modules fail to reload properly. Sometimes the failure >> is intermittent, depending on the order of module loading and other >> esoteric details. Moose and ORM modules seem particularly prone to >> reload failures. For me, this level of unpredictability makes >> *::Reload too frustrating to use. >> >> 2) Catalyst auto-restart >> >> Catalyst has an engine (Catalyst::Engine::HTTP::Prefork::Restarter) >> which forks off a "watcher" process that waits for your modules to >> change. When they change, it restarts the server. The usual effect is >> that, between the time you hit "save" in your editor and reload your >> page, the server has restarted or at least begun restarting. >> >> Problems: Doesn't work well if you make a few changes in a row; the >> restart only captures your first change. Bad user experience if >> there's an error in your module; you have to realize the server has >> died, find the error message in some shell or log, and manually start >> up the server again. >> >> 3) Perrin's MaxRequestsPerChild=1 >> >> Perrin recently alerted me to the MaxRequestsPerChild=1 technique. >> That is, set MaxRequestsPerChild to 1, then load any potentially- >> changing modules in the *child*, not the parent (obviously only for >> development environments). Each request will hit a fresh child server, >> which will load all of your potentially-changing modules anew. >> >> This is the nicest solution I've seen so far. The only problem I can >> see is its performance - each potentially-changing module has to be >> loaded on each request. ** >> >> 4) My idea: Combine 2 and 3 >> >> As in 3, load any potentially-changing modules in the child. Leave >> MaxRequestsPerChild alone. As in 2, fork off a "watcher" process that >> waits for your modules to change. When they change, kill all the >> server's children explicitly. >> >> The end result is that you get reasonable performance when your >> modules don't change (e.g. when you are only futzing with templates), >> but when modules do change, you should see the effects immediately. >> >> This should be able to work with mod_perl, fastcgi, Net::Server, etc., >> as long as the parent server responds appropriately to the killing of >> all its children (by launching new ones). Apache, at least, seems to >> be ok with this. >> >> What do people think? Is this worth codifying in a module, or does >> something like this already exist? >> >> Thanks for any feedback >> Jon >> >> >> ** - You can try to load things only on demand, but often mod_perl >> code is written without 'use' statements as it assumes everything is >> loaded in the parent. You can also try to minimize the number of >> potentially-changing modules, but then you run the risk of leaving >> something off and having to adjust it and restart. >> > -- > Cheers, > Devin Teske > > -> CONTACT INFORMATION <- > Field Engineer > Metavante Corporation > 626-573-6040 Office > 510-735-5650 Mobile > devin.te...@metavante.com > > -> LEGAL DISCLAIMER <- > This message contains confidential and proprietary information > of the sender, and is intended only for the person(s) to whom it > is addressed. Any use, distribution, copying or disclosure by any > other person is strictly prohibited. If you have received this > message in error, please notify the e-mail sender immediately, > and delete the original message without making a copy. > > -> END TRANSMISSION <- > >
Re: a better way to recognize module changes
On Fri, Sep 11, 2009 at 3:20 PM, Devin Teske wrote: > Was there any particular reason that it wasn't packaged with 2.0.4? > (meaning, can I just supplant the one from 2.0.3... or was it removed > only to be re-added after being patched for some particular purpose?) It was not included because of a miscommunication when releasing 0.10. You can install 0.10 from CPAN and should be fine. The conclusions after the post mortem were that the latest stable versions of Apache::* modules should be included with mod_perl core releases, but later versions of those modules should be easily upgradeable from CPAN. > -- > Devin > > > On Fri, 2009-09-11 at 15:11 -0700, Fred Moyer wrote: >> On Fri, Sep 11, 2009 at 3:02 PM, Devin Teske wrote: >> > Maybe somebody can refute what I'm seeing, but as of mod_perl-2.0.4, >> > Apache2::Reload is gone (so you can remove that from your list of >> > options). >> >> It was not bundled with 2.0.4 but is available on CPAN: >> >> http://search.cpan.org/dist/Apache-Reload >> >> It will be bundled again with 2.0.5. There was a discussion on the >> dev list about how to manage perl based Apache2?::* modules with >> mod_perl core releases and the specific version control procedures to >> accomplish this in a pain free manner. >> >> > -- >> > Devin >> > >> > On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote: >> >> I'm thinking about an improved solution to recognizing module changes >> >> in a running server, without restarting the server. >> >> >> >> These are the solutions I know about: >> >> >> >> 1) Apache2::Reload / Module::Reload >> >> >> >> These check whether modules have changed on each request, and if so, >> >> clear their symbols and reload them inside the process. >> >> >> >> Problem: some modules fail to reload properly. Sometimes the failure >> >> is intermittent, depending on the order of module loading and other >> >> esoteric details. Moose and ORM modules seem particularly prone to >> >> reload failures. For me, this level of unpredictability makes >> >> *::Reload too frustrating to use. >> >> >> >> 2) Catalyst auto-restart >> >> >> >> Catalyst has an engine (Catalyst::Engine::HTTP::Prefork::Restarter) >> >> which forks off a "watcher" process that waits for your modules to >> >> change. When they change, it restarts the server. The usual effect is >> >> that, between the time you hit "save" in your editor and reload your >> >> page, the server has restarted or at least begun restarting. >> >> >> >> Problems: Doesn't work well if you make a few changes in a row; the >> >> restart only captures your first change. Bad user experience if >> >> there's an error in your module; you have to realize the server has >> >> died, find the error message in some shell or log, and manually start >> >> up the server again. >> >> >> >> 3) Perrin's MaxRequestsPerChild=1 >> >> >> >> Perrin recently alerted me to the MaxRequestsPerChild=1 technique. >> >> That is, set MaxRequestsPerChild to 1, then load any potentially- >> >> changing modules in the *child*, not the parent (obviously only for >> >> development environments). Each request will hit a fresh child server, >> >> which will load all of your potentially-changing modules anew. >> >> >> >> This is the nicest solution I've seen so far. The only problem I can >> >> see is its performance - each potentially-changing module has to be >> >> loaded on each request. ** >> >> >> >> 4) My idea: Combine 2 and 3 >> >> >> >> As in 3, load any potentially-changing modules in the child. Leave >> >> MaxRequestsPerChild alone. As in 2, fork off a "watcher" process that >> >> waits for your modules to change. When they change, kill all the >> >> server's children explicitly. >> >> >> >> The end result is that you get reasonable performance when your >> >> modules don't change (e.g. when you are only futzing with templates), >> >> but when modules do change, you should see the effects immediately. >> >> >> >> This should be able to work with mod_perl, fastcgi, Net::Server, etc., >> >> as long as the parent server responds appropriately to the killing of >&
Re: a better way to recognize module changes
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz wrote: > It seems like it's available separately in Apache-Reload distribution: > http://cpan.uwinnipeg.ca/dist/Apache-Reload > > But it's already pretty much a straw-man option for me. :) >>> Problem: some modules fail to reload properly. Sometimes the failure >>> is intermittent, depending on the order of module loading and other >>> esoteric details. Moose and ORM modules seem particularly prone to >>> reload failures. For me, this level of unpredictability makes >>> *::Reload too frustrating to use. I've run into issues with reloading ORM based modules such as when I change my DBIx::Class based schema. I get an inconsistent hierarchy error from Class::C3. So in those cases a server restart is required. However, if your model layer is abstracted from mod_perl, you should be able to develop against your model layer using tests, and then install your upgraded model and restart Apache then. The behavior where I encounter problems reloading changes to ORM modules has enforced a good separation of model (ORM) and controller( mod_perl ) code in my application. > > Jon > > On Sep 11, 2009, at 3:02 PM, Devin Teske wrote: > >> Maybe somebody can refute what I'm seeing, but as of mod_perl-2.0.4, >> Apache2::Reload is gone (so you can remove that from your list of >> options). >> -- >> Devin >> >> On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote: >>> >>> I'm thinking about an improved solution to recognizing module changes >>> in a running server, without restarting the server. >>> >>> These are the solutions I know about: >>> >>> 1) Apache2::Reload / Module::Reload >>> >>> These check whether modules have changed on each request, and if so, >>> clear their symbols and reload them inside the process. >>> >>> Problem: some modules fail to reload properly. Sometimes the failure >>> is intermittent, depending on the order of module loading and other >>> esoteric details. Moose and ORM modules seem particularly prone to >>> reload failures. For me, this level of unpredictability makes >>> *::Reload too frustrating to use. >>> >>> 2) Catalyst auto-restart >>> >>> Catalyst has an engine (Catalyst::Engine::HTTP::Prefork::Restarter) >>> which forks off a "watcher" process that waits for your modules to >>> change. When they change, it restarts the server. The usual effect is >>> that, between the time you hit "save" in your editor and reload your >>> page, the server has restarted or at least begun restarting. >>> >>> Problems: Doesn't work well if you make a few changes in a row; the >>> restart only captures your first change. Bad user experience if >>> there's an error in your module; you have to realize the server has >>> died, find the error message in some shell or log, and manually start >>> up the server again. >>> >>> 3) Perrin's MaxRequestsPerChild=1 >>> >>> Perrin recently alerted me to the MaxRequestsPerChild=1 technique. >>> That is, set MaxRequestsPerChild to 1, then load any potentially- >>> changing modules in the *child*, not the parent (obviously only for >>> development environments). Each request will hit a fresh child server, >>> which will load all of your potentially-changing modules anew. >>> >>> This is the nicest solution I've seen so far. The only problem I can >>> see is its performance - each potentially-changing module has to be >>> loaded on each request. ** >>> >>> 4) My idea: Combine 2 and 3 >>> >>> As in 3, load any potentially-changing modules in the child. Leave >>> MaxRequestsPerChild alone. As in 2, fork off a "watcher" process that >>> waits for your modules to change. When they change, kill all the >>> server's children explicitly. >>> >>> The end result is that you get reasonable performance when your >>> modules don't change (e.g. when you are only futzing with templates), >>> but when modules do change, you should see the effects immediately. >>> >>> This should be able to work with mod_perl, fastcgi, Net::Server, etc., >>> as long as the parent server responds appropriately to the killing of >>> all its children (by launching new ones). Apache, at least, seems to >>> be ok with this. >>> >>> What do people think? Is this worth codifying in a module, or does >>> something like this already exist? >>> >>> Thanks for any feedback >>> Jon >>> >>> >>> ** - You can try to load things only on demand, but often mod_perl >>> code is written without 'use' statements as it assumes everything is >>> loaded in the parent. You can also try to minimize the number of >>> potentially-changing modules, but then you run the risk of leaving >>> something off and having to adjust it and restart. >>> >> -- >> Cheers, >> Devin Teske >> >> -> CONTACT INFORMATION <- >> Field Engineer >> Metavante Corporation >> 626-573-6040 Office >> 510-735-5650 Mobile >> devin.te...@metavante.com >> >> -> LEGAL DISCLAIMER <- >> This message contains confidential and proprietary information >> of the sender, and is intended only for the person(s) to
Re: a better way to recognize module changes
On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz wrote: > >> On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz wrote: >>> >>> It seems like it's available separately in Apache-Reload distribution: >>> http://cpan.uwinnipeg.ca/dist/Apache-Reload >>> >>> But it's already pretty much a straw-man option for me. :) >> > Problem: some modules fail to reload properly. Sometimes the failure > is intermittent, depending on the order of module loading and other > esoteric details. Moose and ORM modules seem particularly prone to > reload failures. For me, this level of unpredictability makes > *::Reload too frustrating to use. >> >> I've run into issues with reloading ORM based modules such as when I >> change my DBIx::Class based schema. I get an inconsistent hierarchy >> error from Class::C3. So in those cases a server restart is required. >> >> However, if your model layer is abstracted from mod_perl, you should >> be able to develop against your model layer using tests, and then >> install your upgraded model and restart Apache then. The behavior >> where I encounter problems reloading changes to ORM modules has >> enforced a good separation of model (ORM) and controller( mod_perl ) >> code in my application. > > I'm all for TDD, to be sure, but in practice not everything - especially > with controller and view-specific modules - is going to be developed in this > way. > > I've often exhorted Mason developers to move things out of components into > modules, but a real objection to that has been the server restart cost, and > I've never had a good answer for it. Mason components (like TT templates, > etc.) can pretty much always be reloaded without restart, which I expect is > one reason why so much code ends up there. That makes a lot of sense. Only thing I could suggest would be to exclude your Moose based modules from Apache::Reload reload list if they are causing problems. Although, if there was a way to kill off user owned httpd processes when a code change was made, you could extend Apache::Reload to have certain modules cause httpd recycling vs code reloading. Maybe something like: PerlSetVar ReloadAll On PerlSetVar ReloadHttpds My::Moose So that modules in ReloadHttpds terminates existing user httpd processes and causes the server to fork off new httpd children. > > Jon > >
Re: Why people not using mod_perl
On Wed, Sep 16, 2009 at 2:30 PM, Igor Chudov wrote: > My site algebra.com is about 80,000 lines of mod_perl code. > > I wrote a relatively large framework, with many homegrown perl modules, > about five years ago. > It uses a database, image generation modules, a big mathematical engine that > I wrote (that "shows work", unlike popular third party packages), etc. > > All pages of my site are dynamic and it is very image heavy due to math > formulae. > > I can say two things: > > 1) It is relatively fast, serving pages in 0.1 seconds or so It is fast, just visited it. However, I think you could get a faster initial page load by compressing the html returned to the client using mod_deflate. The main page request was 137 milliseconds and you could probably drop that by 30-50% with gzipping the output. Nice work! > 2) Despite the quantity of code, and its age, it is still very maintainable > and understandable (to me). > > If I was to make a choice again, I would go with mod_perl again. With Perl, > I can "stand on the shoulders of giants" like Lincoln etc, and use the > brilliant stuff they provided to serve my users. Yes, that's why I use mod_perl. The core developers on the Apache Httpd, and mod_perl core are world class.
Re: Why people not using mod_perl
On Wed, Sep 16, 2009 at 8:15 PM, Steven Siebert wrote: > I would also add, in addition to the frameworks, the availability of tools > such as Netbeans and Eclipse IDE's are unmatched in the perl domain. These > IDE's provide many high-level conveniences for enterprise developers, most > notably in the realm of SOA (such as graphical building of BPEL and CEP). Emacs, Vim, Komodo, and others are equally as capable in the Perl domain. What you don't have as much of in the Perl domain is the commercial support for those tools, with the exception of ActiveState. I just pulled down the latest copy of Komodo and took it for a spin; though however many times I try out the GUI based editors I end up going back to cli based tools because they are so much more performant when you've been using them a while and have customized them for your particular needs. I don't doubt there is more support for service oriented architectures with Java based IDEs, as Java tends to be a preferable language for medium and large sized development teams which are easier for larger entities to support. Factors such as productivity per individual developer are less important with a large team. > After nearly 10 years building and maintaining a critical government system, > we are sadly migrating away from mod_perl to a J2EE based solution due to > the success and growth of our mod_perl-based system. mod_perl and MySQL has > served as well when we were taking on medium-to-large loads...however, as we I think this is a natural progression of successful applications. The development needs of a large established system are different than those of a fast growing application. Large systems tend to have more management levels involved, and development speed and scalability are no longer bottlenecks - external systems and compliance tend to be higher priority, and that takes less code writing and more coordination between stakeholders. > Add to this Jeff's comment on the availability of high caliber perl > engineers...we are almost forced to make this decision. Maybe you aren't looking in the right places: http://jobs.perl.org YAPC::* This email list The Perl Mongers groups Dice, Craigslist, Monster, etc. are great places to find Java programmers but bad places to find Perl programmers. In Silicon Valley, you can usually shake a tree and a couple of Java programmers will fall out.. ;) > > We will continue to use mod_perl for other uses, such as our custom SCM/ALM > system we built over the years...but the main product is migrating. > > > On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes wrote: >> >> Doesn't Amazon run mod_perl/Mason? >> >> BTW, I agree with most of your points (would debate #4,5). I may >> substitute the phrase "More convenient" for "Easier" in #3. I would also >> add ... >> >> #7) How many engineers are available to hire that know or want to work >> with said technology? >> >> I built a great platform at eBay on mod_perl/Mason that handled eBay-size >> traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce >> solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade), >> dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java >> app would support ~6 threads per box; the mod_perl platform supported ~60 >> (prefork), significant CapEx and power savings (which adds up at a place >> like eBay). >> >> >> >> >> From: Brad Van Sickle >> To: mod_perl list >> Sent: Wednesday, September 16, 2009 3:31:30 PM >> Subject: Re: Why people not using mod_perl >> >> >> >> This is a mod_perl list, so I would expect to see Perl championed pretty >> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large >> web applications. I'd like to get into some discussion as to why almost all >> *large* sites choose these languages. >> >> I don't have any experience developing a large application in Java, >> although I do have a lot of experience working on the operations side of a >> large web application that is Java based. >> >> The reasons I generally hear for choosing Java over mod_perl are: >> >> 1) Speed - I don't buy this at all >> 2) Maintainability - I think this makes sense. Perl can be pretty easy to >> maintain if you stick a good framework around it, but you have to seek out >> that framework and YOU are responsible for adhereing to it. All of that is >> inherent in Java. It also helps that Java has OO built in. >> 3) Easier to package and build/move code - In my experience this is true. >> 4) Advantages to be gained from running on an actually application server >> - Also valid >> 5) Compatible enterprise class middleware - Also true, Java plugs into >> more truly enterprise level suff than Perl does. (security frameworks, >> etc... ) >> 6) Support >> >> A lot of the industry seems look at Perl as obsolete technology that has >> been replaced by *insert hot new technology of the week here* which is a >> total
Re: Really old bugs (semaphore leak) still in Apache???
On Fri, Sep 25, 2009 at 10:59 AM, Igor Chudov wrote: > [note that this is possibly not am od_perl bug] > > After a little over a month of using apache, and restarting it many times, I > started getting errors such as this one: Is this an apache bug, or a mod_perl bug? If it is an apache bug, have you tried the httpd list? > > No space left on device: Couldn't create accept lock > > The issue is nothing like what the error message suggests: it is not a space > on device issue, the issue is that apache leaks semaphores upon restarts and > runs out of available semaphores. > > This is on Ubuntu Hardy > > I had the same issue on my old Fedora box, so I quickly adapted an old shell > function to delete all semaphores owned by www-data. > > But my question is, Come On! Shouldn't this bug be fixed by now? > > As of now, I added semaphore cleaning to my custom "restart apache" script. > This script already addresses a very obnoxious issue that > "/etc/init.d/apache2 stop" does not always stop apache2. My script does > /etc/init.d/apache2 stop, waits 2 seconds and murders every remaining > instance of apache2. Now it also cleans semaphores. > > But I got to wonder if this bug is ever going to be fixed? > > i >
Re: distributing software built on mod_perl
On Fri, Sep 25, 2009 at 7:32 AM, Mike Barborak 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. Packaging mod_perl apps takes some effort, no doubt. But have you ever tried to package a windows app using msi installer or something similar? The difference in efforts is not significant IMHO. > 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: I tend to rely on Linux distributions to provide the binaries there, so I just need to create an rpm for my own distributions. And the Ovid module on CPAN can make that really easy if you are creating rpms from Perl modules. > 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: Take a look at rpm.pbone.net if you are using Centos or Red Hat. Does that provide what you are looking for?
Re: Alternatives to Apache::DBI?
On Sun, Oct 4, 2009 at 10:17 AM, Bill Moseley wrote: > > On Fri, Oct 2, 2009 at 7:40 PM, David E. Wheeler > Is the history of the ping to catch connections that have been inactive for > a long period and perhaps timed out? I've thought about only issuing the > ping if the $dbh hasn't been fetched in some amount of time (say a few > minutes) to effectively disable the pings when the site is busy (which > should be most of the time). I've thought about this also, but I don't have any data to indicate what that period should be. I use the ping setting with every request. If the database isn't available, I want to know immediately, and I'm willing to foot the overhead of an additional very simple query per each application query I run. I would submit as an additional consideration, that the times when the site is busy are periods where you would want active pings. The database connections are likely to fail when the site is busy than when it is idle, I would postulate.
ApacheCon 2009 in Oakland
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. - Fred
Re: ApacheCon 2009 in Oakland
On Tue, Oct 20, 2009 at 5:43 AM, Jeff Trawick wrote: > On Mon, Oct 19, 2009 at 12:15 AM, Fred Moyer 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. I'll be the guy in the light blue Perl shirt. Shouldn't be hard to find :) I'm going to see about getting some mod_perlish people from SF.pm over. There must be more than one mod_perl hacker in commuting range of the Bay Area besides me :) Tuesday November 3rd in the evening for a mod_perl social? I think that time slot is pretty empty for official activities, and regular conference attendees will likely be arriving around then.
Re: ApacheCon 2009 in Oakland
On Wed, Oct 21, 2009 at 12:34 AM, William A. Rowe, Jr. wrote: > Jeff Trawick wrote: >> On Mon, Oct 19, 2009 at 12:15 AM, Fred Moyer 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! To give this plan some legs, I created an event on the SF.pm Meetup site. Please feel free to syndicate that announcement through appropriate channels. I'm not saying you have to commit to rsvp'ing if you think you might be there, but it would certainly help get some momentum on it. Looking forward to this!
[meetup] ApacheCon 2009 OAK mod_perl and SF.pm Social
Greetings SF Bay Area mod_perl users, Just a quick reminder, this meetup is tomorrow evening at 7pm @Luka's in Oakland CA. http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/11676532/
_apr_bucket_shared_copy symbol not found
Platform: Snow Leopard Versions used: perl 5.10.1, mod_perl 2.0.5-dev, httpd 2.2.14 Error found during make test: t/apr-ext/uuid.t Can't load '/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle' for module APR: dlopen(/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle, 9): Symbol not found: _apr_bucket_shared_copy I compiled apache using the --with-included-apr option. This is a new toolchain setup. Any thoughts?
Re: _apr_bucket_shared_copy symbol not found
On Mon, Nov 16, 2009 at 10:23 AM, Philippe M. Chiasson wrote: > On 09-11-14 14:43 , Fred Moyer wrote: >> >> Platform: Snow Leopard >> >> Versions used: perl 5.10.1, mod_perl 2.0.5-dev, httpd 2.2.14 >> >> Error found during make test: >> >> t/apr-ext/uuid.t Can't load >> '/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle' >> for module APR: >> >> dlopen(/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle, >> 9): Symbol not found: _apr_bucket_shared_copy >> >> I compiled apache using the --with-included-apr option. This is a new >> toolchain setup. Any thoughts? > > Can you send me the exact version of httpd you built, and with what > arguments? > mod_perl Makefile.PL arguments too. I just upgraded to Snow Leopard, so I > should be able to try and reproduce. httpd: ~/dev/httpd-2.2.14 $ ./configure --with-included-apr --prefix=/Users/phred/dev/httpd2/ mod_perl ~/dev/svn/modperl/mod_perl-2.0 $ perl Makefile.PL MP_APXS=/Users/phred/dev/httpd2/bin/apxs I've attached my config.status if that is needed. Made an attempt at inlining it but iterm and gmail don't lend well to doing such things. Thanks for taking a look, let me know if you need any other info. Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=darwin, osvers=10.0.0, archname=darwin-2level uname='darwin pooky.redhotpenguin.com 10.0.0 darwin kernel version 10.0.0: fri jul 31 22:47:34 pdt 2009; root:xnu-1456.1.25~1release_i386 i386 i386 ' config_args='-Dprefix=/Users/phred/dev/perl-5.10.1' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include', optimize='-O3', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -I/opt/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib -L/opt/local/lib' libpth=/usr/local/lib /opt/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -L/opt/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under darwin Compiled at Nov 13 2009 15:49:27 @INC: /Users/phred/dev/perl-5.10.1/lib/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/5.10.1 /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1 config.status Description: Binary data
Re: _apr_bucket_shared_copy symbol not found
On Mon, Nov 16, 2009 at 10:58 AM, Fred Moyer wrote: > On Mon, Nov 16, 2009 at 10:23 AM, Philippe M. Chiasson > wrote: >> On 09-11-14 14:43 , Fred Moyer wrote: >>> >>> Platform: Snow Leopard >>> >>> Versions used: perl 5.10.1, mod_perl 2.0.5-dev, httpd 2.2.14 >>> >>> Error found during make test: >>> >>> t/apr-ext/uuid.t Can't load >>> '/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle' >>> for module APR: >>> >>> dlopen(/Users/phred/dev/svn/modperl/mod_perl-2.0/blib/arch/auto/APR/APR.bundle, >>> 9): Symbol not found: _apr_bucket_shared_copy >>> >>> I compiled apache using the --with-included-apr option. This is a new >>> toolchain setup. Any thoughts? >> >> Can you send me the exact version of httpd you built, and with what >> arguments? >> mod_perl Makefile.PL arguments too. I just upgraded to Snow Leopard, so I >> should be able to try and reproduce. > > httpd: > ~/dev/httpd-2.2.14 $ ./configure --with-included-apr > --prefix=/Users/phred/dev/httpd2/ > > mod_perl > ~/dev/svn/modperl/mod_perl-2.0 $ perl Makefile.PL > MP_APXS=/Users/phred/dev/httpd2/bin/apxs Looks like this was a rogue apr library installed by MacPorts that had gotten into my LDPATH. Saw a similar error building with Crypt::SSLeay and figured out what was going on. All tests successful! > > I've attached my config.status if that is needed. Made an attempt at > inlining it but iterm and gmail don't lend well to doing such things. > > Thanks for taking a look, let me know if you need any other info. > > Summary of my perl5 (revision 5 version 10 subversion 1) configuration: > > Platform: > osname=darwin, osvers=10.0.0, archname=darwin-2level > uname='darwin pooky.redhotpenguin.com 10.0.0 darwin kernel version > 10.0.0: fri jul 31 22:47:34 pdt 2009; root:xnu-1456.1.25~1release_i386 > i386 i386 ' > config_args='-Dprefix=/Users/phred/dev/perl-5.10.1' > hint=recommended, useposix=true, d_sigaction=define > useithreads=undef, usemultiplicity=undef > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include > -I/opt/local/include', > optimize='-O3', > cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN > -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector > -I/usr/local/include -I/opt/local/include' > ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' > -fstack-protector -L/usr/local/lib -L/opt/local/lib' > libpth=/usr/local/lib /opt/local/lib /usr/lib > libs=-ldbm -ldl -lm -lutil -lc > perllibs=-ldl -lm -lutil -lc > libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' > cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup > -L/usr/local/lib -L/opt/local/lib -fstack-protector' > > > Characteristics of this binary (from libperl): > Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL > USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO > Built under darwin > Compiled at Nov 13 2009 15:49:27 > �...@inc: > /Users/phred/dev/perl-5.10.1/lib/5.10.1/darwin-2level > /Users/phred/dev/perl-5.10.1/lib/5.10.1 > /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1/darwin-2level > /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1 >
Re: mod_perl works BUT rtld errors with some modules.
On Thu, Dec 17, 2009 at 1:29 PM, Michael Peters wrote: > On 12/17/2009 04:25 PM, greg.geo...@orica.com wrote: >> >> BTW apache is starting as root and I have confirmed that startup.pl is >> being run as root by apache/mod_perl >> I am going to look in more detail at what DynaLoader.pm does in case >> this gives any clues. > > Not sure if this helps or not, but on some systems LD_LIBRARY_PATH can't be > set by the same process that uses it. So you need it set by the process that > starts the process that uses. So for instance, you need to make sure it's > set in your shell environment and that it gets exported to the commands you > run (sometimes "su" can remove ENV vars). And then you'll need a "PassEnv > LD_LIBRARY_PATH" and a "PerlPassEnv LD_LIBRARY_PATH". But you can't do a > "SetEnv LD_LIBRARY_PATH" in your httpd.conf. > > Not sure if that will help or not though since it's been a while since I've > touched AIX. I remember LD_LIBRARY_PATH issues a few years ago with 64bit and libpaths in /usr/lib64 etc. I was able to resolve that by adding the paths to /etc/ld.so.conf or something similar and then running ldconfig to update the system library paths. No such facility in AIX: http://groups.google.com/group/comp.unix.aix/browse_frm/thread/b9bad793f5e2a475?pli=1
Re: Compile fails with perl 5.10.1
On Sun, Dec 27, 2009 at 2:55 PM, Daniel Hembree wrote: > After upgrading perl to 510.1 I get this compile error for mod_perl-2.0.4. > Perl is compiled with no threads and no multiplicity. Here's the output: Might want to try a 2.0.5 snapshot with 5.10 compatibility. http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution > > perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs MP_COMPAT_1X=0 > ... > > make > cd "src/modules/perl" && make > make[1]: Entering directory > `/home/danny/Projects/mod_perl-2.0.4/src/modules/perl' > cc -I/home/danny/Projects/mod_perl-2.0.4/src/modules/perl > -I/home/danny/Projects/mod_perl-2.0.4/xs -I/usr/local/apache2/include > -I/usr/local/apache2/include -I/usr/local/apache2/include -maltivec > -I/usr/lib/perl5/5.10.1/ppc64-linux-thread-multi-64int-ld/CORE -DMOD_PERL > -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -O3 -fPIC \ > -c mod_perl.c && mv mod_perl.o mod_perl.lo > mod_perl.c: In function ‘modperl_shutdown’: > mod_perl.c:62: error: ‘my_perl’ undeclared (first use in this function) > mod_perl.c:62: error: (Each undeclared identifier is reported only once > mod_perl.c:62: error: for each function it appears in.) > mod_perl.c: In function ‘modperl_hook_post_config_last’: > mod_perl.c:718: error: ‘my_perl’ undeclared (first use in this function) > mod_perl.c: In function ‘modperl_child_exit’: > mod_perl.c:814: error: ‘my_perl’ undeclared (first use in this function) > mod_perl.c: In function ‘modperl_response_handler’: > mod_perl.c:1041: error: ‘my_perl’ undeclared (first use in this function) > mod_perl.c: In function ‘modperl_response_handler_cgi’: > mod_perl.c:1080: error: ‘my_perl’ undeclared (first use in this function) > make[1]: *** [mod_perl.lo] Error 1 > make[1]: Leaving directory > `/home/danny/Projects/mod_perl-2.0.4/src/modules/perl' > make: *** [modperl_lib] Error 2 > > It will compiles and run with perl 5.8.8, , which comes with my YDL-6.2 > distro and uses ithreads. > > any compile suggestions would be appreciated. > > >
Re: unable to compile perl under perl 5.10.1
Have you verified perl was actually compiled with fpic? perl -V On Mon, Jan 11, 2010 at 7:23 AM, Morten Bjørnsvik wrote: > Hi all > I'm unable to compile mod_perl-2.0.x from svn(trunk 2.0.5-dev) or cpan(2.0.4) > on perl 5.10.1, do anyone have some > black belt options that make it works, I believed the -fPIC now is embedded > in the -Dusethreads, because > I see it appear lots of places in the perl compile output > > I've tried compiling perl 5.10.1 with the following options > > ./Configure -des -A ccflags="-O2 -DPERL_USE_SAFE_PUTENV -fPIC" -Dusethreads > -Duse64bitall \ > -Dprefix=/opt/perl -Dinstallprefix=/opt/perl > > ./Configure -des -A ccflags=-DPERL_USE_SAFE_PUTENV -Accflags="-fPIC" > -Dusethreads \ > -Duse64bitall -Dprefix=/opt/perl -Dinstallprefix=/opt/perl > > ./Configure -des -A -Dusethreads -Duse64bitall -Dinstallprefix=/opt/perl > > perl always compiles and seem to work fine with other modules. > > Mod_perl2.0 build: > Both cpan and and the svn checkout version, shows the same error: > build cmd: cd '/usr/tmp/cpan_extract/mod_perl-2.0'; /opt/perl/bin/perl > Makefile.PL MP_APXS=/opt/apache/bin/apxs > > cc -shared -O2 -L/usr/local/lib -fstack-protector \ > \ > mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo > modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo > modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo > modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo > modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo > modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo > modperl_module.lo modperl_svptr_table.lo modperl_const.lo > modperl_constants.lo modperl_apache_compat.lo modperl_error.lo > modperl_debug.lo modperl_common_util.lo modperl_common_log.lo > modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo > modperl_exports.lo -Wl,-E -fstack-protector -L/usr/local/lib > -L/opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE -lperl -lnsl -ldl -lm > -lcrypt -lutil -lpthread -lc \ > -o mod_perl.so > /usr/bin/ld: > /opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE/libperl.a(op.o): > relocation R_X86_64_32 against `a local symbol' can not be used when making a > shared object; recompile with -fPIC > /opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE/libperl.a: could not read > symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [mod_perl.so] Error 1 > make[1]: Leaving directory > `/var/tmp/cpan_extract/mod_perl-2.0/src/modules/perl' > make: *** [modperl_lib] Error 2 > > > Any ideas greatly appreciated. > > Thanks > > Morten Bjørnsvik, Experian Decision Analytics AS, Oslo, Norway > > > >
Re: unable to compile mod_perl under perl 5.10.1
Here's what's on my 5.8.8 with fPIC, I haven't tried 5.10.1 on 64 bit yet. cc='cc', ccflags ='-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', I'm not sure if the perl you showed me below has fpic configured. I recommend that you compile a non-threaded version of perl though in a separate installation location (with fpic configured of course), and then build mod_perl from that. I usually use /home/app_user/perl. There are a couple of reasons to do this: 1) If you start using CPAN with an rpm based distribution such as centos, then you will be installing modules that should be installed via RPM. The Fedora maintainer gave a note on this in a talk a couple years ago at YAPC Chicago. 2) Single threaded perl binaries tend to be faster (~20%) and more stable than threaded perl binaries. I don't have the data to post, but I did some perlbench comparisons a few years ago with 5.8.8. This may have changed with 5.10, but I would consider it unlikely. 3) You can ensure that you have fpic configured. On Tue, Jan 12, 2010 at 12:11 AM, Morten Bjørnsvik wrote: > Hi Fred > > Thanks for the answer. getting correct -fPIC is probably the solution, but > how? > > On perl 5.10.0 it turned up under config flags, but here it does not, but > under cccdlflags in dynamic linking? > There is probably some parsing in the Configure script that rearrange it. > > platform is CentOS 5.2 (latest patches) > > Summary of my perl5 (revision 5 version 10 subversion 1) configuration: > Platform: > osname=linux, osvers=2.6.18-164.9.1.el5, archname=x86_64-linux-thread-multi > uname='linux mortenb5.secana.local 2.6.18-164.9.1.el5 #1 smp tue dec 15 > 20:57:57 est 2009 x86_64 x86_64 x86_64 gnulinux ' > config_args='-des -A ccflags=-DPERL_USE_SAFE_PUTENV -Dusethreads > -Dprefix=/opt/perl -Dinstallprefix=/opt/perl' > hint=recommended, useposix=true, d_sigaction=define > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', > optimize='-O2', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' > ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-46)', > gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 > libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc > perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc > libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a > gnulibc_version='2.5' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' > cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib > -fstack-protector' > > > -Original Message- > From: Fred Moyer [mailto:f...@redhotpenguin.com] > Sent: 11. januar 2010 22:29 > To: Morten Bjørnsvik > Cc: mod_perl list > Subject: Re: unable to compile perl under perl 5.10.1 > > Have you verified perl was actually compiled with fpic? perl -V > > On Mon, Jan 11, 2010 at 7:23 AM, Morten Bjørnsvik > wrote: >> Hi all >> I'm unable to compile mod_perl-2.0.x from svn(trunk 2.0.5-dev) or >> cpan(2.0.4) on perl 5.10.1, do anyone have some >> black belt options that make it works, I believed the -fPIC now is embedded >> in the -Dusethreads, because >> I see it appear lots of places in the perl compile output >> >> I've tried compiling perl 5.10.1 with the following options >> >> ./Configure -des -A ccflags="-O2 -DPERL_USE_SAFE_PUTENV -fPIC" -Dusethreads >> -Duse64bitall \ >> -Dprefix=/opt/perl -Dinstallprefix=/opt/perl >> >> ./Configure -des -A ccflags=-DPERL_USE_SAFE_PUTENV -Accflags="-fPIC" >> -Dusethreads \ >> -Duse64bitall -Dprefix=/opt/perl -Dinstallprefix=/opt/perl >>
Re: Redirect WTF
On Tue, Jan 26, 2010 at 2:58 PM, David E. Wheeler wrote: > Fellow mod_perlers, > > Here's a weird one for you. I'm testing Bricolage on mod_perl 2, getting it > ready for release, and noticed that some sort of redirect is happening when I > don't expect it. > > To whit, I have this configuration: I don't know if this could be an issue, but if I were to write this config snippet, I would create a root block, and put the transhandler outside that (with the other location based directives inside). > > NameVirtualHost *:80 > > DocumentRoot /usr/local/bricolage/comp > ServerName benedict.local > DefaultType "text/html; charset=utf-8" > AddDefaultCharset utf-8 > SetHandler modperl > PerlResponseHandler Bric::App::Handler > PerlAccessHandler Bric::App::AccessHandler > PerlCleanupHandler Bric::App::CleanupHandler > PerlOptions +GlobalRequest > RedirectMatch permanent .*\/favicon\.ico$ > http://benedict.local/media/images/bricicon.ico > TraceEnable off > PerlTransHandler Bric::App::PreviewHandler::uri_handler > > PerlAccessHandler Bric::App::AccessHandler::logout_handler > PerlCleanupHandler Bric::App::CleanupHandler > > > SetHandler modperl > PerlAccessHandler Bric::App::AccessHandler::okay > PerlResponseHandler Bric::App::Handler > PerlCleanupHandler Bric::App::CleanupHandler > > > SetHandler default-handler > PerlAccessHandler Apache2::Const::OK > PerlCleanupHandler Apache2::Const::OK > > > ForceType "text/javascript; charset=utf-8" > > > ForceType "text/css" > > > SetHandler default-handler > > > SetHandler modperl > PerlResponseHandler Bric::SOAP::Handler > PerlAccessHandler Apache2::Const::OK > > > SetHandler modperl > PerlResponseHandler Bric::Dist::Handler > > > ExpiresActive On > ExpiresDefault "now plus 0 seconds" > PerlFixupHandler Apache2::Const::OK > > > > Note that the hosthame is "benedict.local". Now I often just use localhost > when using Bricolage, and most of the time that works fine. But there is one > JavaScript-triggered redirect button that looks like this: > > window.location.href = '/admin/profile/dest?id=1024' > > And when I click it, The request goes to mod_perl and I see it come through > the access handler and the fixup handler as a request to localhost. But then > the PerlReponseHandler never fires! Instead, I see another request come in > for the same URL path, but this time for the host name benedict.local. It's > almost as if something in Apache or mod_perl is seeing that the request is > for a different domain name and helpfully trying to redirect. But it's not > helpful (I get a new login screen), and I don't understand why the same thing > doesn't happen for other requests. > > Is there something like that in mod_perl2 and I'm just missing it? Or is it > more likely that there's some other mysterious bit of code in Bricolage > that's doing it and I just haven't found it yet? If the latter, what comes > between the PerlFixupHandler and PerlResponseHandler? Because in that first > request, the fixup handler fires but the response handler never does. > > TIA, > > David > > > > > > > > > > > > > > >
Snow Leopard wrong architecture error, 'mach-o, but wrong architecture' [mp2]
I have banged my head against this one for a few days but can't get perl 5.10.1, 2.2.14, mod_perl 2.0.5-dev working on Snow Leopard. There are some other similar problems you will find for Snow Leopard through Google, with ruby, python, etc., but none of those have led to a fix for this problem. Here are the relevant errors, any advice appreciated: ph...@pooky ~/dev/svn/sl/trunk/SL-App $ perl bin/sl_app Starting in DEBUG mode Starting with command: /Users/phred/dev/sl/trunk/SL-App/bin/httpd -f /Users/phred/dev/sl/trunk/SL-App/conf/httpd_app.conf -k start httpd: Syntax error on line 32 of /Users/phred/dev/sl/trunk/SL-App/conf/httpd_app.conf: Cannot load /Users/phred/dev/sl/httpd2/modules/mod_perl.so into server: dlopen(/Users/phred/dev/sl/httpd2/modules/mod_perl.so, 10): no suitable image found. Did find: /Users/phred/dev/sl/httpd2/modules/mod_perl.so: mach-o, but wrong architecture ph...@pooky ~/dev/svn/sl/trunk/SL-App $ file ~/dev/sl/httpd2/bin/httpd /Users/phred/dev/sl/httpd2/bin/httpd: Mach-O 64-bit executable x86_64 ph...@pooky ~/dev/svn/sl/trunk/SL-App $ file ~/dev/perl/bin/perl /Users/phred/dev/perl/bin/perl: Mach-O 64-bit executable x86_64 ph...@pooky ~/dev/svn/sl/trunk/SL-App $ file ~/dev/sl/httpd2/modules/mod_perl.so /Users/phred/dev/sl/httpd2/modules/mod_perl.so: Mach-O 64-bit bundle x86_64 Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=darwin, osvers=10.0.0, archname=darwin-2level uname='darwin pooky.redhotpenguin.com 10.0.0 darwin kernel version 10.0.0: fri jul 31 22:47:34 pdt 2009; root:xnu-1456.1.25~1release_i386 i386 i386 ' config_args='-Dprefix=/Users/phred/dev/perl-5.10.1' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O3', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under darwin Compiled at Nov 16 2009 11:36:00 @INC: /Users/phred/dev/perl-5.10.1/lib/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/5.10.1 /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1 .
Re: [mp2] mod_perl closes apache's stdin and/or stdout
On Tue, Jan 26, 2010 at 5:20 PM, Jonathan Swartz wrote:
> This never got a response. Which surprises me, since I think it is a
> legitimate and nasty bug.
>
> So is the silence because
> 1) people don't think it's really a bug
> 2) people glazed over while reading the description
> 3) ??
4) Don't understand how widespread or common this issue is, or if you
are the only one seeing it.
>
> Thanks :)
> Jon
>
> On Jan 8, 2010, at 6:15 AM, Jonathan Swartz wrote:
>
>> (A continuation of:
>> http://marc.info/?l=apache-modperl&m=117507879929572&w=2
>> http://marc.info/?l=apache-modperl&m=119072925228529&w=2
>> )
>>
>> I've just spent many frustrating days debugging a situation that turned
>> out to be caused by mod_perl's closing of file descriptor 1 (STDOUT).
>>
>> Here's the reproducible case I ultimately got it down to. Using mod_perl
>> 2, with a dead-simple configuration and this handler:
>>
>> use DBI;
>> sub handler {
>> my $dbh = DBI->connect( "DBI:mysql:$database", $user, $pass, {
>> RaiseError => 1 } );
>> system('echo "hello"');
>> eval { $dbh->do("select 1") };
>> print "dbh - " . ( $@ ? "error: $...@\n" : "ok" ) . "\n";
>> return 0;
>> }
>>
>> This outputs:
>>
>> dbh - error: DBD::mysql::db do failed: Lost connection to MySQL server
>> during query at...
>>
>> The DBI connection dies because mod_perl closes fd 1 (STDOUT). So the next
>> open - in this case the remote mysql connection created by DBI - gets fd 1.
>> The child process created by system() writes innocently to STDOUT, which
>> goes to our mysql socket, causing havoc.
>>
>> We can confirm this by inserting this at the beginning of the handler:
>>
>> sub handler {
>> open(my $fh, ">/dev/null");
>> print "fh - " . fileno($fh) . "\n";
>> ...
>>
>> Now this outputs:
>>
>> fh - 1
>> dbh - ok
>>
>> The initial open grabs fd 1, which means that DBI gets a different fd, and
>> the connection doesn't die.
>>
>> Now this example is contrived, but replace 'echo "hello"' with any
>> innocuous system() or backtick call that accidentally sends a bit of output
>> to STDOUT, and you can see how this would cause all kinds of baffling bugs.
>> In my case, it was originally a call to "sendmail" that intermittently sent
>> a warning to STDOUT, and thus destroyed our first database connection. It
>> worked fine in mod_perl 1, but started breaking when we upgraded to mod_perl
>> 2.
>>
>> Is there really no way to fix this in mod_perl, perhaps by automatically
>> opening a /dev/null handle as I did above? Other future developers will
>> surely endure the same hours of frustration I did if it is left alone.
>>
>> Thanks
>> Jon
>>
>
>
Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing
What OS are you running? What is the output of 'perl -V'? On Tue, Jan 26, 2010 at 6:19 PM, Pas Argenio wrote: > Sorry if this is naive, but has anyone gotten this combo to work? Upgraded > to Apache 2.2.14, now crash on almost every request, then next httpd picks > up the request and actually displays the page... > > I've got massive core dumps all ending in malloc/free, truss shows last > operation was close() >
Re: mod_perl-2.0.4 with Apache 2.2.9 and perl 5.10.0 intermittent crashing
Perl 5.10.1 is still relatively new, so you might want to give 5.8.9 a shot. That is more heavily vetted on lesser used platforms such as Solaris. On Wed, Jan 27, 2010 at 9:28 AM, Pas Argenio wrote: > I just fell back to Apache-2.2.8 but same problem. By the way, Tosh, how > did you dump the libperl info? > I'm getting more core dumps than you, but pages are displayed by the next > child to pick it up. Here is the most common stack trace (via Solaris' > pstack command): > > Wed Jan 27 09:06:35 EST 2010 > core '/tmp/core' of 13862: /usr/local/apache/bin/httpd -k start > fee56ec8 t_delete (528c90, 228, 0, fecb2e24, fef303a8, c20360) + 74 > fee56ac4 realfree (528a60, 229, d995c, fee56eb0, 0, 528a58) + 8c > fee56610 _malloc_unlocked (528598, 6f8, 528590, ff, 0, 0) + 260 > fee56394 malloc (4c8, 1, da058, fee563a0, fef303a8, fef3a518) + 4c > fec8ae8c Perl_safesysmalloc (4c8, 0, 200, fff8, c04, c329d9) + > 10 > fecc2294 Perl_sv_grow (d17680, 4c8, 0, 200, 4cb, 0) + f8 > fecbd094 Perl_sv_setsv_flags (84408, 4c7, 12c04540, d17680, d177e0, > ff80) + ea0 > fecbd5ac Perl_sv_mortalcopy (d177e0, 5e65d0, fed76000, 78, fed74400, > d17680) + 60 > fecb2e24 Perl_pp_aassign (fed76294, 5b8c20, 5b8c0c, 5b8c1c, 0, fed74400) + > 154 > fecaa830 Perl_runops_standard (0, fecb2cd0, fed75c88, 91c2c0, fed75c00, > 91cec0) + 1c > feca4ce0 Perl_call_sv (fed75c00, fed76000, fed76000, fed75c00, fed75c00, > 91c2c0) + 4a4 > fec1ca94 modperl_callback (0, 44b410, 44b450, ab4b8, 160080, fed76000) + > 338 > fec1d05c modperl_callback_run_handlers (fed75dec, 4, 44b450, 121dc8, ab4b8, > 0) + 31c > fec1d32c modperl_callback_per_dir (6, 44b450, 1, 1, ffbff03c, 214678) + 24 > fec19ab4 modperl_response_handler_run (44b450, 0, 1460, 0, fed761d8, > fed76000) + 18 > fec19cc4 modperl_response_handler_cgi (44b450, 4484b8, 121520, 0, 99070, 9) > + 134 > 0003bfe4 ap_run_handler (44b450, 0, c, 449018, 448728, 0) + 3c > 0003c460 ap_invoke_handler (44b450, 77400, 44b450, 0, fe780020, 0) + b8 > 000547f8 ap_process_request (44b450, 0, 4, 44b450, 0, 443728) + 160 > 00051964 ap_process_http_connection (4436c8, 443430, 443430, 0, 998d0, 2) + > 10c > 00042790 ap_run_process_connection (4436c8, 443430, 443430, 0, 441438, > 4453f8) + 3c > 00067a10 child_main (0, 0, 99c00, 99800, 11177, 99800) + 42c > 00067c74 make_child (67400, 0, 0, fe781020, 440fc8, 0) + ec > 00067d44 startup_children (5, feebd280, 0, 10, 1cf4, a) + 68 > 000686b0 ap_mpm_run (a4878, 99800, ab4b8, 99c00, 99800, 99800) + 950 > 000291f4 main (a4878, 96c00, 99000, 99000, a2870, 0) + 780 > 00028594 _start (0, 0, 0, 0, 0, 0) + 5c > > My MPM is straight pre-fork, default 5 children to start with. > Unfortunately, this stuff needs to go into production soon. > > > > On Wed, Jan 27, 2010 at 11:42 AM, Tosh Cooey wrote: >> >> I'm seeing the same thing on my DEV server which is: >> >> Server: Apache/2.2.11 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0 >> >> I see it in the mornings when it has been sitting around all night doing >> nothing, and the first couple hits result in core dumps/seg faults, then >> after pounding REFRESH like a mad monkey a couple times it then works. >> >> This is on an Amazon EC2 Ubuntu 9.04 jaunty AMI built by Eric Hammond >> http://alestic.com http://ec2ubuntu-group.notlong.com >> >> perl -V: >> >> Summary of my perl5 (revision 5 version 10 subversion 0) configuration: >> Platform: >> osname=linux, osvers=2.6.24-23-server, >> archname=i486-linux-gnu-thread-multi >> uname='linux rothera 2.6.24-23-server #1 smp wed apr 1 22:22:14 utc >> 2009 i686 gnulinux ' >> config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN >> -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr >> -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 >> -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 >> -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 >> -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 >> -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 >> -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl >> -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm >> -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 >> -Dd_dosuid -des' >> hint=recommended, useposix=true, d_sigaction=define >> useithreads=define, usemultiplicity=define >> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef >> use64bitint=undef, use64bitall=undef, uselongdouble=undef >> usemymalloc=n, bincompat5005=undef >> Compiler: >> cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN >> -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE >> -D_FILE_OFFSET_BITS=64', >> optimize='-O2 -g', >> cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing >> -pipe -I/usr/local/include' >> ccversion='', gccversion='4.3.3', gccosandvers='' >> intsize=4, longsize=4, ptrsize=4
Re: [mp2] Apache2::SizeLimit should be using $s->rss, not $s->size for Linux::Smaps
Can you submit these patches inline? http://perl.apache.org/docs/2.0/devel/help/help.html#Submitting_Patches When they are attachments like this, people tend to not read them. Whereas when they are inline, people tend to be able to read them and comment very easily. On Tue, Feb 2, 2010 at 1:58 PM, Max Kanat-Alexander wrote: > All of my processes kept exiting with a report that they had a 300M > unshared size, which was clearly untrue, even from looking at top. After > some investigation, I discovered that Apache2::SizeLimit was calling > $s->size on the Linux::Smaps object, when instead it should be returning > $s->rss as the process size. > > Attached is a one-line patch to fix the issue. > > Also, if you're interested in proof that this is right, I've attached a > short .cgi file that you can load under mod_perl, with Linux::Smaps > installed, to see process sizes and the return values of all of the > Smaps accessors. > > -Max > -- > http://www.everythingsolved.com/ > Competent, Friendly Bugzilla and Perl Services. Everything Else, too. >
Re: Release Distribution
I don't see why we couldn't have both. Breaking anything that links to perl.apache.org/dist/ is no fun for anyone. On Fri, Feb 5, 2010 at 4:18 PM, Philip M. Gollucci wrote: > On 1/31/2010 3:47 PM, Gav... wrote: >> Hi Folks, >> >> I notice you have perl.apache.org/dist/ area in your website directories. >> >> The proper location for distribution is apache.org/dist/perl/ >> >> That second location is what gets picked up by the mirrors for distribution. >> >> That second location is also out of sync, is older than your own /dist/ >> area. >> >> Could you please start using the proper dist location for releases and >> remove >> your own /dist/ area from your website. >> >> Thanks >> >> Gav... >> > I'm not sure what we will do about this. I recall there being a reason > why this is the case. > > -- > > 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C > Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 > VP Apache Infrastructure; Member, Apache Software Foundation > Committer, FreeBSD Foundation > Sr. System Admin, Ridecharge Inc. > Consultant, P6M7G8 Inc. > > Work like you don't need the money, > love like you'll never get hurt, > and dance like nobody's watching. >
Fwd: CPAN Upload: P/PH/PHRED/Apache2-Dispatch-0.13.tar.gz
This version of Apache::Dispatch now has a default namespace of Apache2::Dispatch, along with some fixes for installing seamlessly on mp1 and mp2. It also has a great example section in the Makefile.PL on how to use Apache::Bootstrap to painlessly support your Apache::* and Apache2::* modules on platforms where one or more versions of mod_perl may be installed. If you are thinking about migrating to mod_perl2 from mod_perl1 I highly recommend you take a look at it, as it solves all the painful problems that have plagued dual Apache::* life module maintainers for the past five years. -- Forwarded message -- From: PAUSE Date: Sat, Feb 6, 2010 at 1:20 PM Subject: CPAN Upload: P/PH/PHRED/Apache2-Dispatch-0.13.tar.gz To: Fred Moyer The uploaded file Apache2-Dispatch-0.13.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PH/PHRED/Apache2-Dispatch-0.13.tar.gz size: 23082 bytes md5: 6c37b823c7596bf8b3e8cf8b91df6386 No action is required on your part Request entered by: PHRED (Fred Moyer) Request entered on: Sat, 06 Feb 2010 21:19:17 GMT Request completed: Sat, 06 Feb 2010 21:20:27 GMT Thanks, -- paused, v1048
[RELEASE CANDIDATE] Apache-Test-1.31 RC1
Greetings, Please, download, test, and report back on success or failure for this Apache::Test release candidate. Development from 1.30 has been ongoing for about two years, so this is as good a time as ever to make a release. http://people.apache.org/~phred/Apache-Test-1.31-rc1.tar.gz
Re: [RELEASE CANDIDATE] Apache-Test-1.31 RC1
On Tue, Feb 9, 2010 at 10:20 AM, Adam Prime wrote: > I get the following when trying to run make test: > > waiting 60 seconds for server to start: .Syntax error on line 73 of > /local/aprime/Apache-Test-1.31-rc1/t/conf/httpd.conf: > Invalid command ' included in the server configuration Thanks for the report - RC2 coming shortly which should resolve this. > [ error] > server has died with status 255 (t/logs/error_log wasn't created, start the > server in the debug mode) > sh: line 1: 32276 Terminated /usr/bin/perl > /local/aprime/Apache-Test-1.31-rc1/t/TEST -bugreport -verbose=0 > make: *** [run_tests] Error 143 > > Presumably because apache is compiled without mod_version (which is the > default) > > Adam > > > > Fred Moyer wrote: >> >> Greetings, >> >> Please, download, test, and report back on success or failure for this >> Apache::Test release candidate. >> >> Development from 1.30 has been ongoing for about two years, so this is >> as good a time as ever to make a release. >> >> http://people.apache.org/~phred/Apache-Test-1.31-rc1.tar.gz >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org >> For additional commands, e-mail: dev-h...@perl.apache.org >> > >
[RELEASE CANDIDATE] Apache-Test-1.31 RC2
Greetings, Please, download, test, and report back on success or failure for this Apache::Test release candidate. Development from 1.30 has been ongoing for about two years, so this is as good a time as ever to make a release. http://people.apache.org/~phred/Apache-Test-1.31-rc2.tar.gz This candidate resolves an issue with httpd binaries that were compiled without mod_version, and also adds a fix for the following RT ticket: https://rt.cpan.org/Ticket/History.html?id=21554
Re: [RELEASE CANDIDATE] Apache-Test-1.31 RC2
I'll take that as a +1? :) +1 from me, so that makes 2. Would like to get at least two more +1s from mod_perl devs. Thanks to everyone else who has taken a few minutes to test out this version. On Tue, Feb 9, 2010 at 2:01 PM, Adam Prime wrote: > Passes all tests on 2.2.10 w/ mp 2.0.4 and perl 5.8.8 on linux (ubuntu > hardy). > > Passes all tests on 2.2.14 w/ mp 2.0.4 and perl 5.8.8 on solaris 5.10 > > I tried to run it against our (extremely old) 1.3 setup at work, but i'm > getting weird errors from httpd when i start it up: > > Ouch! ap_mm_create(1048576, "/var/httpd/httpd.mm.2591") failed > Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: > No such file or directory > > Not sure what that's about, but i think it has more to do with works weird > setup than anything else. > > I'll try to remember to run this against some more combinations later > tonight. > > Adam > > > Fred Moyer wrote: >> >> Greetings, >> >> Please, download, test, and report back on success or failure for this >> Apache::Test release candidate. >> >> Development from 1.30 has been ongoing for about two years, so this is >> as good a time as ever to make a release. >> >> http://people.apache.org/~phred/Apache-Test-1.31-rc2.tar.gz >> >> This candidate resolves an issue with httpd binaries that were >> compiled without mod_version, and also adds a fix for the following RT >> ticket: >> >> https://rt.cpan.org/Ticket/History.html?id=21554 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org >> For additional commands, e-mail: dev-h...@perl.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org > For additional commands, e-mail: dev-h...@perl.apache.org > >
Re: CPAN Upload: P/PH/PHRED/Apache2-Dispatch-0.13.tar.gz
On Wed, Feb 10, 2010 at 5:45 AM, Mark Stosberg wrote: > >> Apache2-Dispatch-0.13.tar.gz > > This looks like a useful module, Fred. Geoff Young is the author, I've just been maintaining it. It's a great lightweight and fast dispatcher for PerlHandlers so that you don't have your httpd.conf chock full of Location directives. The userbase isn't that big also, so I get to use it as a proving ground for Apache::Bootstrap. > Is anyone here using this as an initial dispatcher to pass things on to > CGI::Application::Dispatch? I'd love to be able to use it that way but I don't know C:A:D internals well enough. > > Mark > > -- > . . . . . . . . . . . . . . . . . . . . . . . . . . . > Mark Stosberg Principal Developer > m...@summersault.com Summersault, LLC > 765-939-9301 ext 202 database driven websites > . . . . . http://www.summersault.com/ . . . . . . . . > > >
Re: [RELEASE CANDIDATE] Apache-Test-1.31 RC2
On Tue, Feb 9, 2010 at 6:40 PM, Philippe M. Chiasson
wrote:
>
> One small nit, not sure why, but t/next_available_port.t was modified
> and will only be run if mod_cgi *and* mod_cgid is installed, which is
> not very likely. Shouldn't this be what it does instead ?
>
> diff -rdu Apache-Test-1.31-rc2/t/next_available_port.t
> Apache-Test-1.31-rc2.test/t/next_available_port.t
> --- Apache-Test-1.31-rc2/t/next_available_port.t 2009-04-18
> 05:59:26.0 -0400
> +++ Apache-Test-1.31-rc2.test/t/next_available_port.t 2010-02-09
> 21:20:26.0 -0500
> @@ -7,8 +7,7 @@
> use Apache::TestRequest;
> use Apache::TestUtil;
>
> -plan tests => 1, need need_module('mod_cgi.c'),
> - need_module('mod_cgid.c'),
> +plan tests => 1, need need_cgi,
> need_module('mod_env.c');
Yes, thanks for the spot there. Applied.
> Looking at Changes, I can see
>
> "Use need_module('mod_cgi.c') and need_module('mod_cgid.c') in
> t/next_available_port.t instead of need_cgi. On case insensitive file
> systems such as OS X, need_cgi will fulfill the requirement with cgi.pm,
> when mod_cgi.c is the desired requirement.
> [Fred Moyer ]"
>
> Wouldn't the correct solution be to fix need_cgi then :
>
> diff -ru Apache-Test-1.31-rc2.test/blib/lib/Apache/Test.pm
> Apache-Test-1.31-rc2/blib/lib/Apache/Test.pm
> --- Apache-Test-1.31-rc2.test/blib/lib/Apache/Test.pm 2010-02-09
> 13:21:39.0 -0500
> +++ Apache-Test-1.31-rc2/blib/lib/Apache/Test.pm 2010-02-09
> 21:27:47.0 -0500
> @@ -348,7 +348,7 @@
> }
>
> sub need_cgi {
> - return _need_multi(qw(cgi cgid));
> + return _need_multi(qw(cgi.c cgid.c));
> }
Ah, this is a much better approach. I don't think I completely
understood that _need_multi was OR instead of AND last time I looked
at it.
Both changes applied r909744. Thanks Philippe!
[RELEASE CANDIDATE] Apache-Test-1.31 RC3
Third release candidate, a couple of small fixes from Gozer. So far
we've got positive results across the board. Please take this for a
spin if you haven't tried one of the previous release candidates.
http://people.apache.org/~phred/Apache-Test-1.31-rc3.tar.gz
Modify need_cgi so that it looks for cgi.c instead of cgi. This is a fix
for the case insensitive filesystem correction listed below.
[Phillipe M. Chiasson]
t/next_available_port.t doesn't need mod_cgid, use need_cgi instead
of need_module('mod_cgi.c')
[Philippe M. Chiasson]
Re: Apache2::SubProcess sucks
I haven't been following this thread too closely, but is there a
reason you aren't using PerlHandlers instead of ModPerl::Registry?
MP::R is meant mostly for CGI migration, so it is probably not widely
tested with Apache2::SubProcess calls. I'd suggest trying your
external call under a PerlHandler instead and see if that works.
On Fri, Feb 19, 2010 at 1:52 PM, Tosh Cooey wrote:
> Seriously, you know what, the code below doesn't even work.
>
> And if I get rid of the redirect and replace it with some nice pretty text:
>
> print "Content-type: text/html\n\nTesting";
>
> You know what? The warning for 1 (from the 'for' loop) is printed and then
> it all stops, probably as the browser connection "closes".
>
> Hiding it behind more forks made it work once but then never again.
>
> So it is my belief that Apache2::SubProcess sucks dirty things, and that
> belief won't change until I see proof to the contrary.
>
> On a related note, anyone have tips for avoiding zombies in CGI forking?
>
> Tosh
>
>
>
> Tosh Cooey wrote:
>>
>> Hi after much trial and all error I am seeing that the browser connection
>> closing is also stopping my subprocess.
>>
>> The main ModPerl::Registry program looks like this:
>> ### file.pl ###
>> use Apache2::SubProcess ();
>> use JSON();
>>
>> &main(shift);
>>
>> sub main {
>> my $r = shift;
>> ...
>> $r->spawn_proc_prog ('/web/html/file_fork.pl', \...@argv);
>> return print $cgi->redirect('index.pl');
>> }
>> ###
>>
>> And
>>
>> ### file_fork.pl ###
>> use JSON();
>> use warnings;
>> use POSIX 'setsid';
>> chdir '/' or die "Can't chdir to /: $!";
>> open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
>> open STDOUT, '+>>', '/tmp/debug.txt' or die "Can't write to
>> /tmp/debug.txt: $!";
>> open STDERR, '>&STDOUT' or die "Can't dup stdout: $!";
>> setsid or die "Can't start a new session: $!";
>>
>> # run your code here or call exec to another program
>> foreach my $num (1..10) {
>> warn $num;
>> sleep(1);
>> }
>> ###
>>
>> When file.pl is executed it calls file_fork.pl and file_fork starts to
>> print 1, 2, 3 and then stops around 2 or 3 depending on how long my browser
>> is connected.
>>
>> Are there any glaring errors that anyone sees? It should work shouldn't
>> it, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 after 10 seconds...
>>
>> Thank-you all!
>>
>> Tosh
>>
>>
>
> --
> McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
>
Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC
On Tue, Feb 23, 2010 at 10:53 PM, David E. Wheeler wrote: > Fellow mod_perlers, > > I found myself getting this error with mod_perl 2 on 64 bit CentOS this > evening: > > bash-3.2# make test > cd "src/modules/perl" && make > make[1]: Entering directory `/home/dwheeler/mod_perl-2.0.4/src/modules/perl' > rm -f mod_perl.so > cc -shared -O2 -L/usr/local/lib -fstack-protector \ > \ > mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo > modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo > modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo > modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo > modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo > modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo > modperl_module.lo modperl_svptr_table.lo modperl_const.lo > modperl_constants.lo modperl_apache_compat.lo modperl_error.lo > modperl_debug.lo modperl_common_util.lo modperl_common_log.lo > modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo > modperl_exports.lo -Wl,-E -fstack-protector -L/usr/local/lib > -L/usr/local/lib/perl5/5.10.1/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt > -lutil -lc \ > -o mod_perl.so > /usr/bin/ld: /usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.a(op.o): > relocation R_X86_64_32S against `PL_sv_yes' can not be used when making a > shared object; recompile with -fPIC > /usr/local/lib/perl5/5.10.1/x86_64-linux/CORE/libperl.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/dwheeler/mod_perl-2.0.4/src/modules/perl' > make: *** [modperl_lib] Error 2 > > Really annoying. A Googling turned up this post from January: > > http://www.gossamer-threads.com/lists/modperl/modperl/100854 > > Too bad there was never a reply. Anyway, I can say that I set > > export CFLAGS=-fPIC > > Before I built everything on this box, including Perl and Apache 2. Perl says: > > bash-3.2# perl -V | grep PIC > cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic' > > So I'm at a loss here. Any ideas? mod_perl 2.04, perl 5.10.1, apache 2.2.14, > all compiled from source. Haven't tried with 5.10.1, but here's my 5.8.8/2.0.4/2.2.8 settings: perl -V | grep -i fpic cc='cc', ccflags ='-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', cppflags='-fPIC -I/usr/include/gdbm' cccdlflags='-fpic', lddlflags='-shared' Have you tried passing -fPIC at perl configure time when it asks for additional CFLAGS?
[ANNOUNCE] Fwd: CPAN Upload: P/PH/PHRED/Apache-Test-1.31.tar.gz
I'm pleased to announce that Apache::Test 1.31 has been released.
Huge thanks to the modperl and httpd developers who contributed to
this 2.5 year development cycle.
Summary of changes:
Modify need_cgi so that it looks for cgi.c instead of cgi. This is a
fix for the case insensitive filesystem correction listed below.
[Phillipe M. Chiasson]
t/next_available_port.t doesn't need mod_cgid, use need_cgi instead of
need_module('mod_cgi.c') [Philippe M. Chiasson]
PR: 21554 Load mod_apreq2.so if it is available [Derek Price,
]
Add conditional to ignore IfVersion directive if mod_version is not
built. [Adam Prime , Fred Moyer
]
PR: 41239 t/TEST -ping does not return a valid return code to the
calling shell [ozw1z5rd ]
Prevent infinite loop when no default apxs or httpd is present and
repeated attempts to run the test suite under an automated harness
(such as a cpan smoke test). Issue reported by CORION and ANDK, PR:
12911 [Fred Moyer ]
Use need_module('mod_cgi.c') and need_module('mod_cgid.c') in
t/next_available_port.t instead of need_cgi. On case insensitive file
systems such as OS X, need_cgi will fulfill the requirement with
cgi.pm, when mod_cgi.c is the desired requirement. [Fred Moyer
]
Fix overridden get_basic_credentials test when using NTLM
authentication [Rick Frankel ]
Work around a bug introduced in libwww-perl in version 5.820 for
httpd's credentials [Gunnar Wolf , Niko Tyni
]
Make Apache::TestConfig::untaint_path tolerate undefined arguments
[Torsten Foertsch ]
-- Forwarded message --
From: PAUSE
Date: Wed, Feb 24, 2010 at 1:46 PM
Subject: CPAN Upload: P/PH/PHRED/Apache-Test-1.31.tar.gz
To: Fred Moyer
The uploaded file
Apache-Test-1.31.tar.gz
has entered CPAN as
file: $CPAN/authors/id/P/PH/PHRED/Apache-Test-1.31.tar.gz
size: 152080 bytes
md5: 108efa6e33f37c466144617ab3e11456
No action is required on your part
Request entered by: PHRED (Fred Moyer)
Request entered on: Wed, 24 Feb 2010 21:46:26 GMT
Request completed: Wed, 24 Feb 2010 21:46:52 GMT
Thanks,
--
paused, v1048
Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC
On Thu, Feb 25, 2010 at 1:55 PM, David E. Wheeler wrote: > On Feb 24, 2010, at 11:31 AM, David E. Wheeler wrote: > >>> export CFLAGS='-m64 -mtune=nocona'; export LDFLAGS='-L/usr/lib64' >>> ./Configure -des -A ccflags=-fPIC -Dprefix=/opt/perl >>> -Dinstallprefix=/opt/perl >> >> Is that for Perl or for mod_perl? Looks like Perl. > > seems to have worked by rebuilding Perl with: > > CFLAGS='-m64 -mtune=nocona' ./Configure -des -A ccflags=-fPIC > > Should this perhaps be documented somewhere? Absolute - maybe in the INSTALL file? You have commit access right? > > I did get a couple of test failures though: > > t/hooks/authen_basic.t .. > 1..4 > # Running under perl version 5.010001 for linux > # Current time local: Thu Feb 25 16:50:03 2010 > # Current time GMT: Thu Feb 25 21:50:03 2010 > # Using Test.pm version 1.25_02 > # Using Apache/Test.pm version 1.31 > ok 1 > ok 2 > ok 3 > not ok 4 > # Failed test 4 in t/hooks/authen_basic.t at line 26 > Failed 1/4 subtests > ... > t/hooks/authz.t . > 1..4 > # Running under perl version 5.010001 for linux > # Current time local: Thu Feb 25 16:50:04 2010 > # Current time GMT: Thu Feb 25 21:50:04 2010 > # Using Test.pm version 1.25_02 > # Using Apache/Test.pm version 1.31 > ok 1 > ok 2 > ok 3 > not ok 4 > # Failed test 4 in t/hooks/authz.t at line 19 > Failed 1/4 subtests > > Error log attached. > > Thanks, > > David > > > > > >
Re: Error: `PL_sv_yes' can not be used when making a shared object; recompile with -fPIC
On Thu, Feb 25, 2010 at 3:11 PM, David E. Wheeler wrote: > On Feb 25, 2010, at 3:03 PM, Fred Moyer wrote: > >> Absolute - maybe in the INSTALL file? You have commit access right? > > Only to documentation IIRC. I got it just about the time I stopped writing > docs. ;-) I'd suggest either of these pod files: "For an even more detailed documentation refer to: docs/user/install/install.pod docs/user/config/config.pod"
