Re: Getting a / when regex should produce nothing
On Apr 27, 2010, at 4:16 AM, André Warnier wrote:
So, back to the basics, my interpretation : by default, consider
any variable as global/shared and you'll generally stay out of
trouble.
Isn't it true that a variable declared (with my) inside of a
sub (including a handler) starts its existence initialized for
each execution of the sub? So I consider variables declared
outside of any sub global and get along OK without knowing
what lexical scope means, though I may have to learn someday.
That is all I was trying to say in the post that triggered
this thread's recent display of technical erudition.
(*) which is going to be very confusing in the logfile however, as for
now there is no way to distinguish which child logs a message.
For that, we might want to add ($$) to the log messages.
The 3rd field of Apache log file entries is quite useless, and
I have long used it to include the process ID and keepalive status.
Here's my log file format from httpd.conf:
LogFormat %h %l %P:%{Connection}i%{Connection}o %t \%r\ %s %b \%
{Referer}i\ \%{User-Agent}i\ keepalive
Best Regards,
cmac
Re: Getting a / when regex should produce nothing
See what happens if you replace the 2 lines between the should bes
with
if ($article_file =~ /^([a-zA-Z0-9_-]*\.html)$/) {$article_file = $1}
I've can't recall seeing 'undef my' before.
my $error = undef; is more typical.
How is this routine executed? Under ModPerl::Registry?
cmac
On Apr 24, 2010, at 7:47 PM, Chris Bennett wrote:
On 04/24/10 21:38, Chris Bennett wrote:
When I run this first time, with no values from form, I get
$article_file being a / when it should be nothing. I just can't
see the
error. I have tried variations with \w and dash at beginning and end,
but no go.
Debug shows blank at A, / at B
#!/usr/bin/perl
$VERSION = 1.0.0;
use warnings;
no warnings 'uninitialized';
use strict;
#use Apache::Constants qw(:common);
use Apache::Request();
#use Apache::Cookie();
use MyPerl::Articulator qw(get_template print_template print_text
submit_changes backup_server see_html template_form load_template);
our $debug = 1;
delete $ENV{PATH};
my $r = Apache-request;
my $q = Apache::Request-new($r, POST_MAX = 100,
DISABLE_UPLOADS =
1);
my $site_url = www.example.com;
my $site_directory = /var/www/htdocs/users/example.com;
my $site_name = Example!;
my $secure = 1;
my $article_directory = articles;
undef my $error;
undef my $article_title;
undef my $article_backup_file;
undef my $article_file;
$article_file = $q-param(articlefilename);
if ($debug) { $error .= qq{p$article_file/p};}
should be if ($debug) { $error .= qq{pA $article_file/p};}
$article_file =~ m/^([a-zA-Z0-9_-]*\.html)$/;
$article_file = $1;
if ($debug) { $error .= qq{p$article_file/p};}
should be if ($debug) { $error .= qq{pB $article_file/p};}
Re: global variable
Hi, IPC::MMA and its underlying MM library are written entirely in C. I originally got into this business when I read some user reviews that said that the predecessor module IPC::MM was the fastest module of its kind that they could find. IPC::MMA cleaned up several things in IPC::MM, including generalized keys as in Perl hashes. (IPC::MM only allowed C strings as keys.) IPC:MMA is probably faster than IPC::MM. But I've never done any benchmarks to back up this claim, nor against other modules. The direct-call interface is inevitably slightly faster than the tied interface. IPC::MMA only allows sharing among parent and child processes, including between children. The general idea is to create the shared memory, and most or all of the data structures, in the parent process before it forks (e.g., in an Apache PostConfigHandler). If the relationship with the backend daemon isn't parent:child or child:child, you can't use IPC::MMA to share data with the backend daemon. I have to plead ignorance of the fine points of typeglobs. I've used the * notation when an example told me to, without thinking much about it. Having read all the 'typeglob' references in Programming Perl and those in the perl internal docs, they sound like data structures containing addresses of things, i.e., references to things. Except for addresses in shared segments, one process can only access the content of its own memory via addresses, not the memory of other processes. In C, filehandles are just integers, which are eminently sharable. Best Regards, cmac On Feb 4, 2010, at 12:33 AM, Morten Bjørnsvik wrote: Hi We have been using IPC::Cache for this for years, but it does not store typeglobs (filehandlers, sockets etc) Forcing us to use local unix sockets to communicate with the backend daemon. This mean we always have to have a daemon node on every web-server instead of just a single node. I do not see IPC::MMA store typeglobs either, is it faster? We have our own workaround using IPC::SysV and IPC::Msg, they are extremely fast compared to IPC::Cache, but has awkward hash key management I like to drop if we find something faster. Thanks -- Morten Bjoernsvik, Experian Decision Analytics, Oslo, Norway. -Original Message- From: macke...@animalhead.com [mailto:macke...@animalhead.com] Sent: 3. februar 2010 18:18 To: m...@normalperson.e4ward.com Cc: modperl@perl.apache.org Subject: Re: global variable I rewrote IPC::MMA from an earlier CPAN module so that I could use shared memory among Apache children. You can read about it at http://search.cpan.org/~mackenna/IPC-MMA-0.6/MMA.pod On Feb 2, 2010, at 9:45 PM, m...@normalperson.e4ward.com wrote: Hello, Is there a method to setup a global variable for all modperl child processes? Also this variable will be updated sometime, when it get updated, all processes will know it. Thanks.
Re: global variable
Just thought to add: One of the most interesting uses of IPC::MMA is to create a shared memory in a PerlPostConfigHandler, and then use it to tie scalars or arrays or hashes in other modules into the shared memory. In write-seldom, read-mostly applications like the cache hash in Image::Size, this can be done without any change to the other module. cmac On Feb 3, 2010, at 9:20 AM, Boysenberry Payne wrote: Looks like a great module. It says early on in the docs that it doesn't use references; does that mean we need to dereference in order to store that values? Thanks, Boysenberry Payne On Feb 3, 2010, at 10:17 AM, macke...@animalhead.com wrote: I rewrote IPC::MMA from an earlier CPAN module so that I could use shared memory among Apache children. You can read about it at http://search.cpan.org/~mackenna/IPC-MMA-0.6/MMA.pod On Feb 2, 2010, at 9:45 PM, m...@normalperson.e4ward.com wrote: Hello, Is there a method to setup a global variable for all modperl child processes? Also this variable will be updated sometime, when it get updated, all processes will know it. Thanks.
Re: $r-subprocess_env('REQUEST_URI') returns undef ?
If $r scares you, are $c = $r-connection() and $s = $r-server() truly terrifying :-) cmac On Jan 15, 2010, at 4:08 PM, Tosh Cooey wrote: It's probably obvious, but $r kinda scares me. I guess I saw subprocess_env in the docs and so that's where I stopped... What a couple centimeters more would have done...
Re: FreeBSD 7.2, mod_perl2 Apache2::Cookie (libapreq2)
Mr. Sin, I can't tell from your email exactly what isn't working for you, so will assume that you have similar problems as Mr. N. From my experience, the problem may be FreeBSD + libapreq2 2.12. My site runs FreeBSD 6.3. I could not get libapreq2 2.12 and associated Perl linkages (mod_apreq2-20090110/2.7.1) to build from source and pass. The author kept wanting more data about failures, and I'm ashamed to say I stopped answering his requests (it was a bad week). But I did get the package to install from the FreeBSD ports collection, using the following commands: cd /ports/www/libapreq2 # your ports path may be different sudo make clean sudo make install WITH_MODPERL2=yes FORCE_PKG_REGISTER=yes The ports version notes document the included patch that's needed for FreeBSD. It has been working fine for months. Hope this works for either or both of you. Best of luck, cmac On Oct 29, 2009, at 8:22 AM, Sin wrote: Hello, Few weeks back I joined this mailing list to find out about this myself. I've been trying to get apache 2.x and mod_perl2 to run together for many many months now. My target application was OTRS. I've seen apache2 and mod_perl2 work with Debian no problem. I figured I was doing something wrong. I'm not so sure i'm in the wrong at this point after following all readme files to the letter. I've gone back to using apache-1.3.41_1 / mod_perl-1.31_1 Seems like all versions of 1.3 work for the past years, but apache 2 just doesn't want to interface with the application. Its there, installs, but doesn't work. Log files never come up with anything to point to. This apache 2.x and mod_perl2 failed on FreeBSD 6 and 7. Haven't tried 8 yet. - Original Message - From: Joe Niederberger jniederber...@comcast.net To: mod_perl list modperl@perl.apache.org Sent: Tuesday, October 27, 2009 11:04 PM Subject: FreeBSD 7.2, mod_perl2 Apache2::Cookie (libapreq2) Hello, Does anyone have the combination of FreeBSD 7.2, Apache2.2, mod_perl2 and libapreq2 all installed and working fine? My web-hoster is having exterme difficulties getting this set up. The Apache2.so is rife with undefined symbols that they cannot resolve. Simply making a call to the cookie jar and the process segfaults. Any help most appreciated. Thanks in advance. Joe Niederberger
Re: double mod_perl initialization
Been away from my computer for several days :( Doesn't look like anyone is going to answer this. Maybe you missed some of the emails that Clinton Gormley and I were exchanging a while back. I've been using 'sudo apachectl graceful' on apache 2.2.11 and 2.2.13 with mod_perl 2.0.4 and 2.0.5 SVN for many months now and have not noticed any problems. Of course you might be using some feature or module or ??? that my site doesn't, which would cause some problems. Fancy SSL use and changing certificates were mentioned as possibilities. If you look thru the change logs for the various apache versions you can see quite a few improvements for graceful and other restarts (there was one in 2.2.12). So why not give them a chance, and if you have problems come back here and tell us? Or look into them a little and come back and tell us even more? And if graceful restart works OK for you, please send an email to say that. The elimination of superstition is an absolute good. cmac On Oct 2, 2009, at 3:38 PM, Jonathan Swartz wrote: On Oct 2, 2009, at 3:25 PM, Perrin Harkins wrote: On Fri, Oct 2, 2009 at 5:54 PM, Jonathan Swartz swa...@pobox.com wrote: Ok, one more question. Disregarding graceful for the moment - is HUP completely reliable with mod_perl at this point, or is there still a reason (as there once supposedly was) to do a full server stop and start? The problem, at least in the 1.x series, was that the parent process and the perl interpreter never restart. It just re-reads the config file and runs through startup again. Right. Ok, in a *relatively modern Apache/mod_perl 2.x*, is there still a reason to do a full server stop and start? Thanks Jon
Re: double mod_perl initialization
On Sep 25, 2009, at 10:36 AM, Jonathan Swartz wrote: As I understand it, the sole purpose of this double initialization is to make sure that graceful restarts will work. However, since I was a young mod_perl lad I've been taught never to rely on graceful restarts, and always to stop/start. This happens right along: * a bug is found in a piece of software, * the bug gets publicized and responded to and remembered by many people, * the people maintaining the software fix the bug, * but for months and years into the future, people remember the bug and keep working around it. Apache's graceful restart worked fine years ago, but started losing badly at some point. I probably wasn't the only person to write a script called 'graceful' to use instead of 'apachectl graceful'. My log rotation script still uses a variant of 'graceful', but that's mostly because it determines when it's OK to process the log. But at some point, several iterative fixes by the Apache crew had succeeded such that 'apachectl graceful' worked better than my 'graceful' script in some way. It was sufficiently long ago that I've forgotten in what way, but the memory is clear enough that I think Messrs. Swartz and Clint are beating a dead bug. I use 'apachectl graceful' a lot, and can't remember a problem for a long time. Of course problems still exist with older versions of apache2. If they work, graceful restarts are a good thing in that they're as nice as possible to users on a production web site. Double initialization does not prevent problems with restart (graceful or otherwise) for most configuration or perl problems. Isn't that because by the time the root httpd starts the first (re) initialization it has already notified the children (that use the old configuration and code) to go away? So if restart is the reason for double initialization, by all means let's encourage the Apache folks to reconsider the idea, and work around it until they do. cmac P.S. sudo's were omitted for brevity.
Re: double mod_perl initialization
On Sep 26, 2009, at 4:17 AM, Clinton Gormley wrote: I'm using apache 2.2.9, mod_ssl 2.2.9 and mod_perl 2.04, and I still have problems with graceful-restart. You are 4 releases behind. Download 2.2.13 and I bet graceful will work for you. (Bet's off if you have something systemically difficult w/r/t ssl.) Throw in a mod_perl 2.0.5 from SVN: I've never seen such performance as the system I built with 'optimize -Os' last night. In my setup, I know that it can do this, and so I'd rather avoid that double init. I would too. I was defending graceful restart, not double init. cmac
Re: Undefined symbol Perl_pad_sv building mp2 (all is well)
Fred Moyer and Michael Peters were correct about not wanting to have 5.8.x libraries under perl 5.10.1. As soon as I built a 5.10.1 cleanly with no retained libraries, the undef's in Dynaload in mod_perl2 make test went away. The biggest remaining problem was getting apreq2-2.12 to build correctly, which got solved via FreeBSD ports with help from Philip Gollucci. Also included in my upgrade is the most recent mod_perl2 SVN 2.0.5-dev. So Apache 2.2.13, mod_perl 2.0.5-dev, and the patched perl 5.10.1 seem to be happy together under FreeBSD 6.3 on an i386 box. I simplified the patch to perl 5.10.1 and perlbugged it (perl #68986). I think it remains necessary to prevent the Undefined symbol Perl_pad_sv. It now reads in pad.c, move '#ifdef DEBUGGING' from line 915 to line 941. Sorry to have made so much noise on the list getting there. I'll shut up now unless perhaps I can help someone. cmac On Sep 2, 2009, at 2:51 AM, cr...@animalhead.com wrote: Hi Fred, Decided to look at the source found by your 'ack'. It turns out that, in file pad.c, someone in the perl 5.10.0 or 5.10.1 project decided that the Perl_pad_sv routine was only needed if -DDEBUGGING was specified for the Perl build. Fixed this by commenting out the #ifdef DEBUGGING at line 915 of pad.c and the #endif at line 966 of pad.c. (These weren't there in 5.8.9.) Then the compile of pad.c didn't work. A macro used by one of the two newly-included routines was missing. Fixed this by commenting out the #ifdef DEBUGGING at line 6076 of proto.h, and the #endif at line 6082 of proto.h. With these changes perl5.10.1 built, passed all its tests, and installed fine. It works in various scripts too! On to testing mod_perl2. Did make veryclean, perl Makefile.PL, and make without any hangups. (There were probably some warnings during make but I didn't watch carefully.) make test no longer gets the Undefined symbol Perl_pad_sv. Unfortunately it now fails in a different way: == animalhead:/build/mod_perl-2.0.4 $ 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/mod_perl-2.0.4/t -f /build/ mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2 using Apache/2.2.13 (prefork MPM) waiting 120 seconds for server to start: .Use of uninitialized value in subroutine entry at /usr/local/lib/perl5/5.10.1/i386- freebsd/DynaLoader.pm line 91. Use of uninitialized value in subroutine entry at /usr/local/lib/ perl5/5.10.1/i386-freebsd/DynaLoader.pm line 200. Use of uninitialized value in subroutine entry at /usr/local/lib/ perl5/5.10.1/i386-freebsd/DynaLoader.pm line 200. .. ... waiting 120 seconds for server to start: not ok [ error] giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT to a high value (e.g. 420) and repeat the last command. [ error] server failed to start! (t/logs/error_log wasn't created, start the server in the debug mode) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ *** Error code 1 Stop in /build/mod_perl-2.0.4. animalhead:/build/mod_perl-2.0.4 $ == The bug report info that I submitted at the end of this thread probably still applies. Anyone's suggestion what to do now will be appreciated. I feel like holding off telling the perl project about the undefined symbol until this problem is solved too. cmac On Sep 1, 2009, at 10:36 PM, Fred Moyer wrote: On Tue, Sep 1, 2009 at 10:14 PM, cr...@animalhead.com 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
Re: [mp2] Apache2::Reload missing in FreeBSD ports
I run FreeBSD + Apache2 + mp2. CPAN 'test Apache::Reload' yields 'pass'. Subsequent CPAN 'test Apache2::Reload' wants to use the same module, so it says 'Has already been tested successfully'. cmac On Sep 3, 2009, at 3:59 AM, Foo JH wrote: Hello guys, I'm wondering if there is any1 using FreeBSD + Apache2 + mp2. In short: there's no Apache2::Reload. I browsed around the web (in particular http://www.mail-archive.com/ d...@perl.apache.org/msg12048.html) , and apparently I'm not the only one who noticed it. People mention Apache::Reload, but on my FBSD7.2: 1. Installing p5-Apache-Reload over package (at v0.07) throw out: Can't locate object method dir_config via package Apache2::RequestRec at /usr/local/lib/perl5/site_perl/5.8.8/ Apache/Reload.pm line 51. 2. I can't install p5-Apache-Reload over ports, as it will complain it expects Apache 1.3. Any advice will be appreciated. Thanks.
Re: Undefined symbol Perl_pad_sv building mp2 (resolved but all not well)
Hi Fred, Decided to look at the source found by your 'ack'. It turns out that, in file pad.c, someone in the perl 5.10.0 or 5.10.1 project decided that the Perl_pad_sv routine was only needed if -DDEBUGGING was specified for the Perl build. Fixed this by commenting out the #ifdef DEBUGGING at line 915 of pad.c and the #endif at line 966 of pad.c. (These weren't there in 5.8.9.) Then the compile of pad.c didn't work. A macro used by one of the two newly-included routines was missing. Fixed this by commenting out the #ifdef DEBUGGING at line 6076 of proto.h, and the #endif at line 6082 of proto.h. With these changes perl5.10.1 built, passed all its tests, and installed fine. It works in various scripts too! On to testing mod_perl2. Did make veryclean, perl Makefile.PL, and make without any hangups. (There were probably some warnings during make but I didn't watch carefully.) make test no longer gets the Undefined symbol Perl_pad_sv. Unfortunately it now fails in a different way: == animalhead:/build/mod_perl-2.0.4 $ 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/mod_perl-2.0.4/t -f /build/ mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2 using Apache/2.2.13 (prefork MPM) waiting 120 seconds for server to start: .Use of uninitialized value in subroutine entry at /usr/local/lib/perl5/5.10.1/i386-freebsd/ DynaLoader.pm line 91. Use of uninitialized value in subroutine entry at /usr/local/lib/ perl5/5.10.1/i386-freebsd/DynaLoader.pm line 200. Use of uninitialized value in subroutine entry at /usr/local/lib/ perl5/5.10.1/i386-freebsd/DynaLoader.pm line 200. . waiting 120 seconds for server to start: not ok [ error] giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT to a high value (e.g. 420) and repeat the last command. [ error] server failed to start! (t/logs/error_log wasn't created, start the server in the debug mode) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ *** Error code 1 Stop in /build/mod_perl-2.0.4. animalhead:/build/mod_perl-2.0.4 $ == The bug report info that I submitted at the end of this thread probably still applies. Anyone's suggestion what to do now will be appreciated. I feel like holding off telling the perl project about the undefined symbol until this problem is solved too. cmac On Sep 1, 2009, at 10:36 PM, Fred Moyer wrote: On Tue, Sep 1, 2009 at 10:14 PM, cr...@animalhead.com 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
Re: Undefined symbol Perl_pad_sv building mp2
On Sep 2, 2009, at 6:21 AM, Michael Peters wrote: cr...@animalhead.com 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. Pure Perl modules should work between versions (they might have some new warnings, but they should work), but anything with XS (C code) isn't guaranteed to work across major versions. So when you've upgraded between say 5.8.2 and 5.8.7 you wouldn't need to re- install. But when upgrading from 5.8.X to 5.10.X you will need to re-install. If you aren't up to being rigorous, be lucky: everything (except mod_perl build, see crossed email with resolved in title) works for me so far. Hopefully most modules for which this would be an issue are covered by upgrades, which get installed at the top (5.10.1) level. What does make problems is that CPAN sometimes deletes modules in an earlier-version directory when installing a new module in the current-version directory. This tends to break the lower-level perl w/r/t module availability. So I copy the earlier-version directories before an upgrade session, and run a sync program thereafter. 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. If you need 5.8.7 libs that you can't re-compile against 5.10.1 then just stick with 5.8.7. I had a case like that in the current transition: my IHP's CGI control panel works under 5.8.9 but logs taint warnings under 5.10.1. So I just ran a script that changed all of its bang lines to 5.8.9. Sometimes one has to admit that life is too short to tilt with every problem. 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? Yes, the perl you use when you run the Makefile.PL is the one that's used in the compilation of mod_perl. Thank you for this valuable information! It should be in the mod-perl documentation. (Bet it's not in there now, I looked pretty hard.) Hope someone who can do that reads this suggestion. -- Michael Peters Plus Three, LP
Re: Undefined symbol Perl_pad_sv building mp2
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... cmac On Aug 30, 2009, at 11:49 AM, Fred Moyer wrote: On Sat, Aug 29, 2009 at 9:43 PM, cr...@animalhead.com 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.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,
Re: Undefined symbol Perl_pad_sv building mp2
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. 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, cr...@animalhead.com 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, cr...@animalhead.com 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, cr...@animalhead.com 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
Undefined symbol Perl_pad_sv building mp2
-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. 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=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt -lutil -lc perllibs=-lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV
Re: RFC: Apache2::CloseKeepAlive
On Aug 27, 2009, at 10:43 AM, Bill Moseley wrote: On Wed, Aug 26, 2009 at 3:43 AM, cr...@animalhead.com wrote: The short story is that it's a mod_perl2 mechanism for optimizing the KeepAlive option in the Apache2 server. The long story is at http://www.animalhead.com/CloseKeepAlive.html Interesting. But, is there really a probem to solve here? Is the point here to free up mod_perl processes faster so that they can handle other connections? Does that really have anything to do with better performace in serving up pages? Yes that's the point, but I would substitute 'apache processes' for 'mod_perl processes'. My site's front page preloads sixty-some jpg thumbnails. Years ago it was evident that KeepAlive On was needed to allow this to complete in a reasonable length of time. e.g., on a 1.5M ADSL line it takes 2-3 seconds with KA on, 6-8 seconds with KA off. So it seems that connection establishment and process dispatch take a while. Even though the Javascript that does the preloading on my front page only requests 3 images ahead of download completion, the response shown to a quick user clicking on a link is noticeably degraded by the preload stream. So you want to get the preloading over with before most users will click on a link. I decided to write this module about a year ago, when I read an article that the latest Firefoxes would open up to 6 connections to download supporting files, and that the MSIE team was considering leapfrogging them to 8. With my cheapskate ISP plan limiting the total number of processes, hanging 6 or 8 of them at a time (with a plain KeepAlive On) was a pretty scary idea. I don't think you can look at file extensions and determine when to close the connection. Can you count on how the browser will send requests? Maybe not strictly, but in general browsers request files in the order they are requested in the .html file. In the case of a lot of .jpg's the browser may take their relative file sizes into account. For example, javascript probably should be loaded last in the HTML file. Javascript that is involved in building the pages wants to get called out as early in the header as possible, either before or after the css. JavaScript that only interacts with the user could come last, but by doing that you take the chance of responding badly to a quick user. Then the bulk of images are often loaded via css. Are you scanning the css, too? The scanning script that accompanies the module could easily do this. I will count your email as a first request for that feature, and if I get 2 or 3 I'll add it. If that happens, can I count on you for a sample of a .css that loads images? What if you have multiple servers? Connections will be on different machines. Clearly that's a different environment than CloseKeepAlive is designed for. If customizing the keep alive is that critical then I think it's time to look at other techniques. Use a balancer and let it decided how to manage the connections (perlbal keeps the connection open forever). Anything that keeps a connection open forever is going to end up with a lot of connections? Use sprite sheets to reduce the number of required connections. I looked up sprite sheets and they seem to be graphics that include lots of little tiled figures used in video games. How does a browser know to split them up into separate images that pages can then call out individually? Use a CDN and cache static content forever -- and rarely hit your serve. In the end, each page view should only be one request to your mod_perl server anyway. My site uses all defined headers to encourage proxies and browsers to cache files. The performance of a site is the cross-product of all of the things that it does to improve performance. But you can't just look at it from the server's point of view. CKA is motivated by a desire to give the best possible performance/ responsiveness at the browser, that's consistent with keeping the load on the server reasonable.
RFC: Apache2::CloseKeepAlive
I'm working toward contributing a module with this working title to CPAN, and would like your comments and advice. The short story is that it's a mod_perl2 mechanism for optimizing the KeepAlive option in the Apache2 server. The long story is at http://www.animalhead.com/CloseKeepAlive.html I'm tentatively convinced it's worth contributing, but you're welcome to tell me why it's not. For sure, your advice on how to improve it will be very welcome. Specifically: • What CPAN module(s) is (are) most like this one, to use as model(s) for how to package, test, and install it? • The plan is to use Module::Build and Apache::Test. What else or something different? • Is something as specialized as this worth including in the GP Perl libraries? Or is it better to just ask where the mod_perl2 library is? • Is inclusion in the GP Perl libraries a prerequisite or assumption of Module::Build or of CPAN? In addition to where to put the module itself, it needs a place to put a companion DB-building app and a place for the resulting DB. These are not standard features of a module installation. Probably I just ask the user where they should go? If so, how do I use the answers? Thanks for being there, cmac
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 7:03 AM, Perrin Harkins wrote: What's GP Perl? The general purpose Perl library is headed at /usr/local/lib/perl5 on my system. What I was asking is whether there's any reason to put Apache2::CloseKeepAlive in it, being as it's so specialized, or just copy it to a mod_perl2-specific library (/usr/local/apache2/plib on my system). Maybe the latter if the user says such a thing exists, else the former? cmac
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 9:05 AM, Perrin Harkins wrote: On Wed, Aug 26, 2009 at 11:41 AM, cr...@animalhead.com wrote: The general purpose Perl library is headed at /usr/local/lib/perl5 on my system. What I was asking is whether there's any reason to put Apache2::CloseKeepAlive in it, being as it's so specialized, or just copy it to a mod_perl2-specific library (/usr/local/ apache2/plib on my system). Maybe the latter if the user says such a thing exists, else the former? You don't get to choose that. You just do a standard Module::Build distribution, and if people want to install your module somewhere outside of the site_lib, they specify that at install time. - Perrin How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place.
Re: RFC: Apache2::CloseKeepAlive
Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. If that's against CPAN principles, the principles need some work! cmac On Aug 26, 2009, at 9:30 AM, Perrin Harkins wrote: On Wed, Aug 26, 2009 at 12:21 PM, cr...@animalhead.com wrote: How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place. It's in the docs for Module::Build. Seriously, you have no control over where users install your module. Attempting to control it is against the principles of CPAN distributions. - Perrin
Re: RFC: Apache2::CloseKeepAlive
The installation process needs to know at least: 1. where the accompanying DB-building script should go 2. where the DB that the app builds should go How can such necessary things be determined, other than by asking the user? I was just going to add a note before or after these two queries, that if they have a mod_perl2 library and want the module to go there, they should do this. As I just wrote to Perrin off-list, since only a tiny fraction of CPAN downloads are mod_perl2 modules, no one can configure CPAN for a mod_perl2 library. Perhaps my attitude toward installation dialogs has been warped by recent experience with my previous CPAN module IPC::MMA. The install for version 0.54 contained no prompts. Its results came out 75% unknown, because few test environments included a necessary C library 'mm'. One of the chief testers suggested I should add Devel::CheckLib to Makefile.PL. So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it prompts the user to enter the path to 'mm', which is then passed to Devel::CheckLib. The query is accompanied by a note showing the URL from which 'mm' can be downloaded. On the other hand, my latest version 0.58 has only been tested by one tester, a week after uploading it. Maybe that's because of the new query in Makefile.PL! Best Regards, cmac On Aug 26, 2009, at 10:44 AM, Michael Peters wrote: cr...@animalhead.com wrote: Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. Please don't put a dialog in your installation process! CPAN is supposed to be automatic after it's been configured. There are some rare occasions where it makes sense to ask some questions, but where you want the module installed is not one of them. CPAN takes care of that. -- Michael Peters Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 11:44 AM, Michael Peters wrote: cr...@animalhead.com wrote: The installation process needs to know at least: 1. where the accompanying DB-building script should go Module::Build knows where to put bin/ or script/ files and it does so according to how Perl and CPAN are configured. I assume EU::MM does too. So if I put the script in a subdirectory bin of Apache2- CloseKeepAlive-n.nn/, the install step should automatically put it somewhere in the path. This is good information, thank you! I have no idea what EU::MM is. Candy from Europe? 2. where the DB that the app builds should go That's probably something your application should allow to be specified, either a command line option to the script or an option to the module, or both. My plan was to run the script the first time under Build.PL, to verify that it succeeds and because without the DB there can be no testing. In which case, asking the user where to put the DB, and propagating the answer to the script source and the module source, seems to me like the easiest course for everyone. This kind of prompt is not evil, in that the automated testers can be handled by giving the query a default, maybe '/tmp'. How can such necessary things be determined, other than by asking the user? If it's a run time option (and can be changed or multiple programs can use this and thus want different values) don't ask for it at install time. It's not a run time option. The subject is a mod_perl2 script, that can only be used within the Apache2 server. I can't conceive why the DB name would ever change, and multiple programs won't use the module. I was just going to add a note before or after these two queries, that if they have a mod_perl2 library and want the module to go there, they should do this. Putting extra docs in your module is ok, but I personally wouldn't repeat the docs that are already out there. I personally regard docs already out there as things that should be restated in here whenever the user can profit from them. As I just wrote to Perrin off-list, since only a tiny fraction of CPAN downloads are mod_perl2 modules, no one can configure CPAN for a mod_perl2 library. All perl libraries should go in the same place IMO. Whether it's Apache specific, or GTK or something else. I don't want to have to mess with @INC just because someone put something someplace non- standard. It seems that you and Perrin are in the same boat, which has One Perl Library For All painted on it. I am in a different boat with the authors of various mod_perl books. I set up my site under the guidance of Practical mod_perl p. 34: Now you have to select a directory where all the mod_perl scripts and modules will be placed. We usually create a directory called modperl under our home directory for this purpose (e.g., /home/stas/modperl), but it is also common to create a directory called perl under your Apache server root, such as /usr/local/apache/perl. (It's /usr/local/apache2/plib on my site.) This theme is echoed on p. 58 of the mod_perl2 User's Guide: You often need to adjust the contents of @INC before the server starts, usually to give the server additional places to look for your mod_perl code. There are several ways to do this: • startup.pl In the startup file you can use the lib pragma like so: use lib qw(/home/httpd/projectl/lib/tmp/lib); use lib qw(/home/httpd/project2/lib); • httpd.conf In httpd.conf you can use the PerlSwitches directive to pass arguments to Perl as you do from the command line. PerlSwitches -I/home/httpd/projectl/lib -I/tmp/lib PerlSwitches -I/home/httpd/project2/lib And on p. 61 of the mod_perl Developer's Cookbook: For a similar option, configure your startup.pl as use lib qw(/home/www/lib); ... By default, mod_perl adds two directories to @INC: ServerRoot/ and ServerRoot/lib/perl/, where ServerRoot is the value of the ServerRoot directive. ... If you are using a startup.pl to preload your modules, you will probably need to take advantage of the use lib syntax. Given all this, I blithely talk about the mod_perl library as if it's a standard part of every mod_perl site, and you and Perrin regard me as someone from another planet. Which is actually true, but that's another story. So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it prompts the user to enter the path to 'mm', which is then passed to Devel::CheckLib. The query is accompanied by a note showing the URL from which 'mm' can be downloaded. Personally, I'd just bomb out if you can't find the lib (and Devel::CheckLib is good for that). Give the user a message that you can't find the library and then exit. I doubt that someone who has a library that's not in the system libs will know where it is, and if they do they can just as easily set LD_LIBRARY_PATH themselves. This happens to me fairly regularly when
What can a child_init do?
Is there anything a mod_perl2 child_init phase can do to call attention to a problem? I moved a block of code from a post_config handler to a new child_init handler, without thinking much about the niceties of the move. The code contained a couple of 'die' statements, which I trust would prevent an Apache startup if executed in a post config handler. Q1: WOULD 'DIE' IN A POST_CONFIG HANDLER ABORT AN APACHE2 STARTUP? In the child_init handler, an executed 'die' did nothing noticeable. Specifically the message did not end up in the error_log. In the mod_perl2 doc pages, child_init is described as being 'of type void', which another page says means that the return value doesn't matter. I will change the 'die' to a '$s-log_error', and return the nastiest- sounding Apache return code I can find, in hopes that some future Apache might notice it. Q2: IS THERE ANYTHING A CHILD_INIT PHASE CAN DO TO ABORT ITS CHILD PROCESS, AND THUS CALL ATTENTION TO A SERIOUS PROBLEM? It's amusing that the 'child_init' process seems to be an orphan in the Apache2 world... Thanks in advance, cmac www.animalhead.com
problem porting to threaded mode
Trying to shift our largely mod_perl2 web site to an Apache2 threaded
MPM and perl ithreads.
The following works under the non-threaded prefork MPM:
use DB_File;
my @dbs; # array of hash references
my @dbModTime; # mod times of db files
my @dbfns; # array of database pathnames
# executed before fork into child processes
sub post_config {
my $db;
my $s = $_[3];
# tie the DBs and get their mod times
for ($db = 0; $db @dbfn; $db++) {
$dbs[$db] = {};
tie %{$dbs[$db]}, DB_File, $dbfn[$db], O_RDONLY
or die ((caller 0)[3]. can't tie . $dbfn[$db] . : $!);
$dbModTime[$db] = (CORE::stat($dbfn[$db]))[9]
or die ((caller 0)[3]. can't stat . $dbfn[$db] . : $!);
} }
The routines that use the databases re-stat the DB files and untie and
re-tie a DB
that has changed. Each child process must do this for itself.
In the threaded environment, any thread within a process may discover
that such
an untie and re-tie is necessary, but such an operation should be
effective
for the other threads in the process as well. This means that @dbs and
@dbModTime should be shared among the threads:
use threads;
use threads::shared;
my @dbs :shared; # array of hash references
my @dbModTime :shared; # mod times of db files
Making only the changes above makes perl complain Invalid value for
shared scalar
about the '$dbs[$db] = {};' line. This error message can be fixed as
follows:
for ($db = 0; $db @dbfn; $db++) {
$dbs[$db] = shared_clone({});
tie %{$dbs[$db]}, DB_File, $dbfn[$db], O_RDONLY
or die ((caller 0)[3]. can't tie . $dbfn[$db] . : $!);
$dbModTime[$db] = (CORE::stat($dbfn[$db]))[9]
or die ((caller 0)[3]. can't stat . $dbfn[$db] . : $!);
$s-log-notice ($dbfn[$db]. has .scalar(keys(%{$dbs[$db]})).
entries);
}
Unfortunately, when this is done the server starts, but the DBs look
empty and
the log notices for each DB show 0 entries.
Removing the ':shared' tag for @dbs and the 'shared_clone()' wrapper
for '{}'
causes the log notices to show the proper number of entries for each DB,
but blows up the Apache configuration process (before the 'resuming
normal
operations' message) with
httpd in free(): error: chunk is already free
in error_log and the following on the terminal:
Abort trap (core dumped)
Error invoking apachectl start command
I guess not having databases is better. I've tried using @dbs as an
array of
references to named, shared hashes: also no database content. The
'worker'
and 'event' MPMs work identically w/r/t this problem.
Suggestions of things to try will be very welcome.
Happy New Year, cmac
Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11 RESOLVED
Dropped back in configuration and component programs to a working combination, then advanced in smaller steps than I had done before. You were correct, Mr G, in your prediction that the lib tree was involved. The 'Undefined symbol PL_markstack_ptr' in the mod_perl2 'make test' step: 1. appeared as soon as an option was added that changed the names of the architecturally dependent lib directories, and 2. went away when I removed the three old architecturally-dependent directories that I had tried to preserve, from the colon separated list of additional lib directories. As a general statement of this, I would nominate: when changing Perl build options that change the names of architecturally-dependent lib directories, don't try to keep old arch-dependent directories in @INC. With the note that such dependent directories contain hyphenated elements like 'i386-freebsd'. Thanks for your help, cmac On Dec 27, 2008, at 11:44 PM, Philip M. Gollucci wrote: Philip M. Gollucci wrote: Craig MacKenna wrote: On Dec 24 00:57, Philip M. Gollucci pgollu...@p6m7g8.com wrote: Subject: Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11 If you post your ./Configure for perl, ./configure for httpd, and perl Makefile.PL for mod_perl, I'll run it locally on my freebsd boxes. http://people.apache.org/~pgollucci/mp2bug.txt FWIW, I do this nearly weekly, so I'm not really expecting it to fail, but hey first time for everything. Works like a charm though a few tests fail b/c its the event mpm as expected. I stand by what I said before 1) clean up your perl lib tree 2) verify /usr/bin/perl is correctly symlinked to /usr/local/bin/ perl
Info about mp2 and threaded MPMs
I'm about to try a threaded MPM for my largely mod_perl2-based web site. Maybe my search skills are going downhill, but I haven't found much material about how to modify my scripts for the threaded environment. The first step is done, namely to minimize use of global variables. I'm pretty sure that the few that remain need to be marked as shared and in some cases need to have mutual exclusion zones around their use. It's confusing that Apache2 and perl5.8 have separate mutual-exclusion mechanisms. For no good reason my instinct is to use the Apache2 mutexes. Comments on the mutual exclusion alternatives will be welcome, as will suggestions for printed or online books, tutorials, and other words about threading and mod_perl2. Thanks and HNY, cmac www.animalhead.com
Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11
On Dec 24 00:57, Philip M. Gollucci pgollu...@p6m7g8.com wrote: Subject: Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11 cr...@animalhead.com wrote: Neither mod_perl 2.0.4 nor the current build modperl-2.0_20081223052020 If you're going to do that 'current build', I'd use revision numbers of SVN instead of the data. The page on the mod_perl site about what to do before submitting a problem report suggested trying the current build from the location I used, as a data point for the overall report. So I complied with those instructions. If some other source is better, perhaps the web page in question wants editing. PL_markstack_ptr This isn't perl 5.8.8 vs perl 5.8.9 related, if you diff the trees, only 1 line is changed - *PL_markstack_ptr = (p) - PL_stack_base;\ + *PL_markstack_ptr = (I32)((p) - PL_stack_base);\ PL_markstack_ptr is in the error message that occurred. Perhaps it's no longer exported, or global'ed, or whatever the right term is nowadays? MP_APXS= /usr/local/apache2/bin/apxs *** /usr/local/apache2/bin/httpd -V You did not install www/apache22 port, but rather compiled by hand ? It has been years since I compiled or assembled anything by hand, but I do go back in the software field to 1963, when such things were sometimes still done. All of several set of instructions I have read, as to how to build mod-perl, have recommended the apxs method. *** /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 9) configuration: So this isn't in the ports tree yet, so you also compiled perl by hand I have never had anything to do with the ports facility, and have built all of our site's software from source for years. The build sequences used for Aapche 2.2.11, perl 5.8.9, and mod-perl 2.0.4 have all been used on previous occasions with full success. The big change is building 2.2.11 for the event MPM. @INC: /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/vendor_perl/5.8.9 /usr/local/lib/perl5/vendor_perl/5.8.7 Looks like your perl tree has some history, I'd try with a clean tree .. my money is here. The Perl5.8.9 in question has worked very well with the previous prefork Apache 2.2.10 and a mod-perl built against it. A clean tree approach is complicated by the fact the tree has essential modules in it from my internet hosting provider (IHP), mostly in the vendor-perl branch but perhaps in other branches as well. *** Packages of interest status: mod_perl : 1.29 mod_perl2 : 2.03, 2.05 Speaking of clean trees, that can't be good. you have multiple versions of mod_perl2 installed which almost certainly means that you'll get a mix match between .pm and .so files. I'd clean that up My IHP provides a large number of .so's in the include directory, and I just let the mod-perl 2.0.4 that I built exist next to the 2.0.3 from my IHP's original setup. This has never caused any problems in the past. (httpd.conf calls out the 2.0.4.so.) But on your advice I will rename the 2.0.3 with an extra .hide after the .so, and retry the thing as soon as I get back to my development machine next Monday. FWIW I'm startled by the 2.05 but I assume that's because the last thing built was the _20081223052020 on the recommendations of the mod_perl web site. FWIW, you really shouldn't install your own perl into /usr/local/bin/perl on FreeBSD you should put yours somewhere else. There is great value to me in having a single perl that is used for all applications, rather than a my perl and their perl and the perl used by that other gang over there. For example, commonality of use of Berkeley DBs by perl programs from various sources discourages having multiple Perl binaries in use. (Older perl's are still around for reference but nothing uses them on our site.)
Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11
As Adam Prime notes, 5.8.9 became the current stable Perl recently. It is the other new ingredient besides Apache 2.2.11. I don't normally introduce so many new things at once, but happen to be working through a new sandbox/developmental version of our website. One of the Apache developers suggested I should wait for 5.10.1, so that's why I'm futzing with 5.8.9. I don't know why the bug-report- generating script would lie to us about what Perl I'm using. Oooh your os? Was that your machine doing something bad as you were typing? I won't be doing development for most of a week, but if you have any other questions, I'll be monitoring email. Is there anything else I should get through so that you will take a deeper look at this? If so please advise. Happy Holidays, cmac On Dec 22, 2008, at 11:25 PM, Philip M. Gollucci wrote: PL_markstack_ptr Thats a perl function its irrelevant of httpd versions. Are you use you are using the /usr/local/bin/perl below ? *** /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 9) configuration: Platform: osname=freebsd, osvers=6.3-release, Oooh my os, now you're in trouble. -Dusethreads -Dusemultiplicity -Duseithreads -Duse64bitint' usethreads=define use5005threads=undef useithreads=define usemultiplicity=define perl 5.8.9 is not in the ports tree yet, how did you install perl, its also not a GA release, its a Release Candidate (RC) If you get through all that, I'll take a deeper look. Also, does this not happen with 2.2.10 though that should be irrelevant.
[mp2] undefined symbol in make test with threaded Apache 2.2.11
This is my first attempt at using a threaded MPM. Sorry but I don't have time to try prefork build of Apache 2.2.11. Leaving town tomorrow but will monitor email for comments on this. Thanks, cmac www.animalhead.com -8-- Start Bug Report 8-- 1. Problem Description: Neither mod_perl 2.0.4 nor the current build modperl-2.0_20081223052020 play well with apache 2.2.11. Both get the following error message shortly after entering 'make test': mod_perl-2.0.4 $ 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/mod_perl-2.0.4/t -f /build/ mod_perl-2.0.4/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.11 (event MPM) waiting 120 seconds for server to start: .httpd: Syntax error on line 17 of /build/mod_perl-2.0.4/t/conf/httpd.conf: Cannot load /build/ mod_perl-2.0.4/src/modules/perl/mod_perl.so into server: /build/ mod_perl-2.0.4/src/modules/perl/mod_perl.so: Undefined symbol PL_markstack_ptr 2. Used Components and their Configuration: *** mod_perl version 2.04 *** using /build/mod_perl-2.0.4/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.11 (Unix) Server built: Dec 22 2008 22:17:00 Server's Module Magic Number: 20051115:21 Server loaded: APR 1.3.3, APR-Util 1.3.4 Compiled using: APR 1.3.3, APR-Util 1.3.4 Architecture: 32-bit Server MPM: Event threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/experimental/event -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_SCOREBOARD=logs/apache_runtime_status -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 (0x2820a000) libm.so.4 = /lib/libm.so.4 (0x2821b000) libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x28231000) libaprutil-1.so.3 = /usr/local/apache2/lib/libaprutil-1.so. 3 (0x2825d000) 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 8 subversion 9) configuration: Platform: osname=freebsd, osvers=6.3-release, archname=i386-freebsd-thread- multi-64int uname='freebsd sakomina.securesites.net 6.3-release freebsd 6.3- release #2: wed jun 25 14:30:46 mdt 2008 r...@fc:usrsrcsysi386compilevkern i386 ' config_args='-Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/ perl5/5.8.7/i386-freebsd:/usr/local/lib/perl5/5.8.7:/usr/local/lib/ perl5/site_perl/5.8.7/i386-freebsd:/usr/local/lib/perl5/vendor_perl/ 5.8.7/i386-freebsd -Dvendorprefix=/usr/local -Dmyhostname=www - Dmydomain=animalhead.com -Dusethreads -Dusemultiplicity -Duseithreads -Duse64bitint' 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=define 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=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib'
content_type in SSI- or directly-called mp2 scripts
My mod_perl2 scripts mostly fall into 2 categories:
1) scripts that are called by URL location, and generate complete
content-pages
2) scripts that are called by SSI include virtual sequences
in .html files, and generate part of a page
In some cases scripts of type 1 directly call scripts of type 2 to
generate parts of their pages.
(Call this case 3).
My questions are about when to call $r-content_type('text/html')
Such a call is a good idea in category 1, right?
Such a call probably should not be made by the directly-called script
in case 3, right?
Apache probably can't even tell that a new script has gotten into the
act, the calling
and called script are both in the undifferentiated sea of mod-perl
code, right?
In an SSI-invoked script (category 2) is a content_type call a)
required, b) good practice,
or c) a bad idea?
Thanks,
cmac
www.animalhead.com
[mp2] make test errors
-8-- Start Bug Report 8--
1. Problem Description:
Per suggestion made in this forum, I gave up on static build and am
building dynamic.
Now I get 2 errors in make test, plus undef errors during 'sudo make
install'
t/hooks/authen_basic1..4
# Running under perl version 5.008008 for freebsd
# Current time local: Fri Nov 14 21:00:32 2008
# Current time GMT: Sat Nov 15 05:00:32 2008
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.31
ok 1
ok 2
ok 3
# Failed test 4 in t/hooks/authen_basic.t at line 26
not ok 4
FAILED test 4
Failed 1/4 tests, 75.00% okay
t/hooks/authz...1..4
# Running under perl version 5.008008 for freebsd
# Current time local: Fri Nov 14 21:00:33 2008
# Current time GMT: Sat Nov 15 05:00:33 2008
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.31
ok 1
ok 2
ok 3
# Failed test 4 in t/hooks/authz.t at line 19
not ok 4
FAILED test 4
--- also, in the subsequent 'sudo make install', every module was
tagged with:
Use of uninitialized value in length at /usr/local/lib/perl5/5.8.8/
ExtUtils/Command/MM.pm line 134.
So I changed said line 134 from
if (length $options{perm_rw}) {
to
if ($options{perm_rw}) {
Which made a subsequent retry of 'sudo make install' go without error
messages
---
2. Used Components and their Configuration:
*** mod_perl version 2.04
*** using /build/mod_perl-2.0.4/lib/Apache2/BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB = aprext
MP_APXS= /usr/local/apache2.2.10/bin/apxs
MP_COMPAT_1X = 1
MP_DEBUG = 1
MP_GENERATE_XS = 1
MP_LIBNAME = mod_perl
MP_TRACE = 1
MP_USE_DSO = 1
*** /usr/local/apache2.2.10/bin/httpd -V
Server version: Apache/2.2.10 (Unix)
Server built: Nov 14 2008 19:37:16
Server's Module Magic Number: 20051115:18
Server loaded: APR 1.3.3, APR-Util 1.3.4
Compiled using: APR 1.3.3, APR-Util 1.3.4
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.2.10
-D SUEXEC_BIN=/usr/local/apache2.2.10/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.2.10/bin/httpd
/usr/local/apache2.2.10/bin/httpd:
libz.so.3 = /lib/libz.so.3 (0x28208000)
libm.so.4 = /lib/libm.so.4 (0x28219000)
libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x2822f000)
libaprutil-1.so.3 = /usr/local/apache2.2.10/lib/libaprutil-1.so.3
(0x2825b000)
libexpat.so.6 = /usr/local/lib/libexpat.so.6 (0x2827a000)
libapr-1.so.3 = /usr/local/apache2.2.10/lib/libapr-1.so.3 (0x2829b000)
libcrypt.so.3 = /lib/libcrypt.so.3 (0x282c3000)
libpthread.so.2 = /lib/libpthread.so.2 (0x282db000)
libc.so.6 = /lib/libc.so.6 (0x282ff000)
*** (apr|apu)-config linking info
-L/usr/local/apache2.2.10/lib -laprutil-1 -lexpat -L/usr/local/lib
-L/usr/local/apache2.2.10/lib -lapr-1 -lcrypt -lpthread
*** /usr/local/bin/perl5.8.8 -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=freebsd, osvers=6.3-release, archname=i386-freebsd
uname='freebsd sakomina.securesites.net 6.3-release freebsd 6.3-
release #2: wed jun 25 14:30:46 mdt 2008
[EMAIL PROTECTED]:usrsrcsysi386compilevkern i386 '
config_args='-Doptimize=-g -Dusedevel'
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 ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -
DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement -
I/usr/local/include',
optimize='-g',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DDEBUGGING -fno-
strict-aliasing -pipe -Wdeclaration-after-statement -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=4, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-Wl,-E -L/usr/local/lib'
libpth=/usr/lib
Re: [mp2] build (make) error and 2 questions
please see below On Nov 12, 2008, at 10:07 PM, Philip M. Gollucci wrote: Fred Moyer wrote: On Wed, Nov 12, 2008 at 9:30 PM, [EMAIL PROTECTED] wrote: -8-- Start Bug Report 8-- 1. Problem Description: 1.1 attempting to static-build mod_perl 2.0.4 and apache 2.2.10, is the following warning right at the end of the Makefile.PL output worrisome? [warning] mod_perl static library will be built as mod_perl.a Not worrisome, mod_perl just did not build. Can you build as a shared object rather than compiling it into Apache statically? perl Makefile.PL MP_APXS=/path/to/my/httpd2/bin/apxs Static hasn't worked for a long time in 2.x though it is on the infinite list; however, the performance reasons for doing it statically are not really an issue in 2.x -- -- -- Philip M. Gollucci ([EMAIL PROTECTED]) c: 703.336.9354 snip Fred: mod_perl did not build YET? (This warning is only at the end of the Makefile.PL output, and it is phrased in terms of how it WILL be built.) Or am I on the wrong page in saying this? Of course I could build statically, but (old saying) that's not the swamp I set out to drain. Philip: but I liked the idea of a static build? Not just for operational performance, but for startup performance and perhaps for some possible better integration of the symbol tables for debugging? Are you saying that the 1.2 error cannot be worked around, and I should just give up on the static build idea? Like I had to on perl SSI's (!--#perl...) a while back? Would anyone like it if I hacked through problems with building statically, and contributed the changes? And can anyone please answer 1.3 even if it would be better sent to the main Apache side? The pain of subscribing to mailing lists is proportional to the square of the number of lists. 1.3 is --enable-debug still valid as an Apache 2.2.10 configure option, or is it completely superceded by --enable-maintainer-mode? The Apache docs no longer mention --enable-debug. Compiling some of the ssl stuff (in an Apache build without mod-perl) made warnings about prototypes... Thanks, Craig MacKenna www.animalhead.com
[mp2] build (make) error and 2 questions
-8-- Start Bug Report 8-- 1. Problem Description: 1.1 attempting to static-build mod_perl 2.0.4 and apache 2.2.10, is the following warning right at the end of the Makefile.PL output worrisome? [warning] mod_perl static library will be built as mod_perl.a 1.2 errors in make, after about 37 cc's have succeeded: --- cc -I/build/mod_perl-2.0.4/src/modules/perl -I/build/mod_perl-2.0.4/ xs -I/build/httpd-2.2.10/include -I/build/httpd-2.2.10/srclib/apr/ include -I/build/httpd-2.2.10/srclib/apr-util/include -I/build/ httpd-2.2.10/os/unix -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H - DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement - I/usr/local/include -I/usr/local/lib/perl5/5.8.8/i386-freebsd/CORE - DMOD_PERL -DMP_COMPAT_1X -DMP_DEBUG -DMP_TRACE -g -c modperl_exports.c modperl_exports.c:1169: error: `modperl_thx_interp_get' undeclared here (not in a function) modperl_exports.c:1173: error: `modperl_thx_interp_set' undeclared here (not in a function) *** Error code 1 Stop in /build/mod_perl-2.0.4/src/modules/perl. *** Error code 1 Stop in /build/mod_perl-2.0.4. -- 1.3 is --enable-debug still valid as an Apache 2.2.10 configure option, or must this be --enable-maintainer-mode instead? Compiling some of the ssl stuff (last night before venturing into mod-perl) made warnings about prototypes... NOTE: the contents of the shell script used to initiate Makefile.PL are attached right before the end bug report line the near the end. 2. Used Components and their Configuration: *** mod_perl version 2.04 *** using /build/mod_perl-2.0.4/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_AP_CONFIGURE = --prefix=/usr/local/apache2.2.10 --with- mpm=prefork --with-included-apr --with-ssl=/usr/local/ssl --enable- debug --enable-exception-hook --enable-mods-shared='all authn_alias cache disk_cache mem_cache charset_lite dav_lock ext_filter logio proxy proxy_connect proxy_ftp proxy_http proxy_ajp proxy_balancer' -- enable-authn_file=static --enable-authn_default=static --enable- authz_host=static --enable-authz_groupfile=static --enable- authz_user=static --enable-authz_default=static --enable- auth_basic=static --enable-include=static --enable-filter=static -- enable-log_config=static --enable-env=static --enable-expires=static --enable-setenvif=static --enable-mime=static --enable-status=static --enable-autoindex=static --enable-asis=static --enable-cgi=static -- enable-negotiation=static --enable-dir=static --enable-alias=static -- enable-actions=static --enable-deflate=static --enable-expires=static --enable-file_cache=static --enable-ssl=static --enable-suexec=static --with-suexec-uidmin=80 --with-suexec-gidmin=80 --with-suexec- caller=www --with-suexec-userdir=www/cgi-bin --with-suexec-docroot='/ home' --with-pcre=/usr/local/bin/pcre-config CFLAGS='-DVERIO - DVERIO_VPS' LDFLAGS='-L/usr/local/lib' MP_AP_DESTDIR = /usr/local/apache2.2.10 MP_AP_PREFIX= /build/httpd-2.2.10 MP_COMPAT_1X= 1 MP_DEBUG= 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_TRACE= 1 MP_USE_STATIC = 1 *** The httpd binary was not found *** (apr|apu)-config linking info -L/build/httpd-2.2.10/srclib/apr-util/.libs -L/build/httpd-2.2.10/srclib/apr-util -laprutil-1 -lexpat -L/usr/ local/lib -L/build/httpd-2.2.10/srclib/apr/.libs -L/build/httpd-2.2.10/srclib/apr -lapr-1 -lcrypt -lpthread *** /usr/local/bin/perl5.8.8 -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=freebsd, osvers=6.3-release, archname=i386-freebsd uname='freebsd sakomina.securesites.net 6.3-release freebsd 6.3- release #2: wed jun 25 14:30:46 mdt 2008 [EMAIL PROTECTED]:usrsrcsysi386compilevkern i386 ' config_args='-Doptimize=-g -Dusedevel' 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 ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H - DDEBUGGING -fno-strict-aliasing -pipe -Wdeclaration-after-statement - I/usr/local/include', optimize='-g', cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DDEBUGGING -fno- strict-aliasing -pipe -Wdeclaration-after-statement -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',
Re: Two failures in make test building mod_perl 2.0.3
Hi tomás, Info is filled in below. One other Q: what is the protocol for when to reply to just one person (reply) vs. the whole list (reply all)? Best Regards, Craig On Jan 19, 2007, at 4:25 AM, [EMAIL PROTECTED] wrote (in part): Hm. Looks sane to me. But somehow 'localhost' seems to resolve (sometimes) to 127.0.0.1 on your machine. What does nslookup localhost (or any FreeBSD equivalent thereof) say? Server: 127.0.0.1 Address:127.0.0.1#53 Name: localhost Address: 127.0.0.1 How does the /etc/nsswitch.conf look like? group: compat group_compat: nis hosts: files dns networks: files passwd: compat passwd_compat: nis shells: files I still guess that this is a resolver issue, not a modperl one. Regards - -- tomás
More on Apache2::Request does not foul up content length
This is getting rather embarrassing. It turns out that my whole problem was that the Mail::CheckUser package that I was using to check submitted email addresses, always takes several minutes to return a result on the new (FreeBSD6) system, while it often returns a result in a few seconds on the old (FreeBSD4) system. So of course the response to the form submission took several minutes. I will pursue this difference with my ISP and the author of the package. Sorry to have bothered the list about such a thing... Craig MacKenna Los Gatos, CA
Apache2::Request fouls up content length?
I'm still hoping for a good answer on my previous build problem. But for now I'm proceeding with testing using the mod_perl that my hosting provider set up. The first script that I've tested that uses Apache2::Request gives a problem. The browser sits and waits for its timeout period, then the complete expected response is available. My limited experience suggests this is probably because the response's content-length value is fouled up (or the header isn't sent?). My server signature is Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 mod_apreq2-20051231/2.5.7 mod_perl/2.0.2 Perl/v5.8.7 Server at mackenna1.securesites.net OS is FreeBSD 6. The problem happens under both http: and https:. mod_deflate and mod_include are also active for the transaction. Anyone can see the problem at http://mackenna1.securesites.net/contact.html which is the site's contact form. If you just hit send without entering anything, you'll get a response that says you didn't enter anything, but it will take a long time. Apache2::Request had bigger problems until I included the following line in httpd.conf: LoadModule apreq_module modules/mod_apreq2.so That .so was also provided by my hosting provider (Verio). Does this sound familiar? Could it be avoided by newer versions of any of the software? Craig MacKenna Los Gatos, CA
Re: Apache2::Request fouls up content length?
Jonathan, thank you for your replies! The client I'm testing with is, in most contexts, not slow. It's a dual-processor 1.25 MHz PowerMac on a DSL line, with the Safari browser which does most things faster than any other PC or Mac browser I've used. Thought I had a solution: since my two pages containing forms are both under SSL, I put KeepAlive On in the virtual host for 80, and KeepAlive Off in the virtual host for 443. Unfortunately this did not fix the problem, from an SSL page. Apache::Request worked with KeepAlive under Apache 1 and mod_perl 1. So I feel like things have gone backward... My front page downloads a series of 80+ small jpg's, and the impact of a general KeepAlive Off on that operation is unacceptable. The complexity of a multi-server / multi-apache setup is more than I want to deal with. I much prefer KeepAlive on a single Apache to using Apache2::Request on a multi-server solution. It's easy enough to get the form data and parse it myself. 1. Do you think the problem is in mod_perl or apreq2? 2. Does that module have a bug reporting system (other than this mailing list) ? 3. Is there a known bug for Apache2::Request vs. KeepAlive? 4. If not, where can I post one, so this can be fixed for other people? Thanks for your help, Craig MacKenna www.animalhead.com On Jan 18, 2007, at 5:26 PM, Jonathan Vanasco wrote: On Jan 18, 2007, at 8:14 PM, [EMAIL PROTECTED] wrote: You are correct. Turning off keepalive fixes the problem. (We're on a VPS so we have control of httpd.conf.) My residual problem is that neither KeepAlive nor MaxKeepAliveRequests is allowed in a Location block, so I can't just do one of them for the scripts that use Apache2::Request. Anyone have a way to keep KeepAlive and Apache2::Request? Might newer versions of any of the software involved fix the problem? Thanks much, Craig MacKenna www.animalhead.com personally, I would suggest this: forget about keepalive in modperl don't run mod_perl on port 80. run a proxy on it -- either apache or something lightweight like nginx run your app on port 80xx using its own apache. have keepalive turned off. keepalive can be turn on in your port 80 dae,pm serve static off the proxy, only hit up mp for dynamic content. its not as fast as if you had keepalive on the proxied connection, but its still considerably faster than not-proxying , and you don't deal with any of the issues of a slow-client tying up your modperl process there's a section in the modperl book explaining the multi-server / multi-apache setup in depth. its online, via google // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Two failures in make test building mod_perl 2.0.3
-8-- Start Bug Report 8-- 1. Problem Description: Two failures in make test building mod_perl 2.0.3 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /tmp/mod_perl-2.0.3/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_AP_PREFIX = /www MP_CCOPTS = -march=pentiumpro MP_COMPAT_1X = 0 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 *** /www/bin/httpd -V Server version: Apache/2.2.3 Server built: Aug 9 2006 10:27:21 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.2, APR-Util 1.2.2 Compiled using: APR 1.2.2, APR-Util 1.2.2 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 /www/bin/httpd /www/bin/httpd: libssl.so.4 = /usr/lib/libssl.so.4 (0x28113000) libcrypto.so.4 = /lib/libcrypto.so.4 (0x28142000) libm.so.4 = /lib/libm.so.4 (0x28239000) libaprutil-1.so.2 = /usr/local/apache2/lib/libaprutil-1.so.2 (0x2824f000) libdb41.so.1 = /usr/local/lib/libdb41.so.1 (0x28267000) libexpat.so.6 = /usr/local/lib/libexpat.so.6 (0x28303000) libapr-1.so.2 = /usr/local/apache2/lib/libapr-1.so.2 (0x28324000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x2834a000) libpthread.so.2 = /usr/lib/libpthread.so.2 (0x28362000) libc.so.6 = /lib/libc.so.6 (0x28387000) *** (apr|apu)-config linking info -L/usr/local/apache2/lib -laprutil-1 -ldb41 -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 8 subversion 8) configuration: Platform: osname=freebsd, osvers=6.0-release, archname=i386-freebsd-64int uname='freebsd mackenna1.securesites.net 6.0-release freebsd 6.0- release #19: wed sep 20 14:24:06 mdt 2006 [EMAIL PROTECTED]:usrsrcsysi386compilevkern i386 ' config_args='-Doptimize=-march=pentiumpro -des -Uusethreads - Duse64bitint' 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=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno- strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/ include', optimize='-march=pentiumpro', cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict- aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion='', gccversion='3.4.4 [FreeBSD] 20050518', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -lm -lcrypt -lutil -lc perllibs=-lm -lcrypt -lutil -lc libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under freebsd Compiled at Jan 17 2007 15:07:11 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/local/lib/perl5/5.8.8/i386-freebsd-64int /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/i386-freebsd-64int /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl . *** Packages of interest status: Apache2: - Apache2::Request : - CGI: 3.25 ExtUtils::MakeMaker: 6.30 LWP: 5.805 mod_perl : - mod_perl2 : - 3. This is the core dump trace: (if you get a core dump): none This report was generated by t/REPORT on Thu Jan 18 07:21:59 2007 GMT. -8-- End Bug Report
Code Serialization and mod_perl
Hello, Please help me understand how Perl with mod_perl handles the following situation. Consider 2 clients out in the WWW using the same form to work on 2 different records of the same type. At submission, the form executes a database function and passes the data entered using the form. The function retrieves the data from the CGI-like connection, assigns the data to Perl dataspaces and begins processing the code series of the function. Now the 2nd client executes the function in the same way, right on the heels of the 1st client. In the C language in a network environment, when a client calls a database function in a DLL to access a server database, a system semaphore is is used to serialize code access to prevent the corruption ofdataspaces. With only Perl, a different Perl interpreter instance is started for each CGI request. The instances don't know about each other and dataspaces are unique to an instance. How does Perl with mod_perl handle this. Are there any important differences with the only Perl situation. Might the dataspaces be corrupted? How does this work? My technical environment is Windows XP Home, Apache 2.0.049, Perl 5.8.3, and mod_perl 2.0.2. Thank you in advance for any responses. I appreciate your time. Craig Tussey [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Outgoing content-length apparently 0
Hope this is the address to which to send a problem/question!
Our Verio Virtual Private Server is FreeBSD-based with Apache 1.3.33.
I've installed mod-perl 1.29 and mod_gzip 1.3.19.2a, and revised our former
CGI scripts to run as perl modules under the Apache API.
They are operating fine, except for one residual problem.
When a script builds a response, mod_gzip squawks in the error_log like
this:
... [error] mod_gzip: EMPTY FILE [/tmp/_16777_106_7.wrk] in sendfile2
... [error] mod_gzip: Make sure all named directories exist and have ...
The corresponding entry in access_log looks like this:
... POST /contact HTTP/1.1 200 0or
... GET /x/whoami.cgi HTTP/1.1 200 0
The zero outgoing length in the log entry agrees with mod_gzip's complaint,
but in reality the correct body is going out to the browser (I was the
browser user for both of the access_log cases above). The former case
(contact) runs under mod_perl, while the latter runs under mod_cgi.
Today I tried an approach to solving this, wherein I build up the whole body
in a scalar $body, and then do a
send_response('text/html');
where send_response is:
sub send_response {
$r-header_out(Content-Length, length $body);
$r-send_http_header(shift);
if (!$r-header_only) {$r-print($body)}
undef $body;
}
The problem still persists. So I searched our logs. The first 200 0 log
entry for a script was seen before I installed mod_gzip, and after I
followed the advice of the Practical mod-perl book, and moved all of the
scripts from /usr/local/apache/cgi-bin to a new directory
/usr/local/apache/perl. Before that the scripts had been running fairly
correctly under mod_perl and Apache::Registry in .../cgi-bin, without
showing any 200 0 log entries for scripts.
None of the following changes in httpd.conf seem to affect the problem:
PerlSendHeaders On/Off
PerlSetupEnv On/Off
Option +ExecCGI in the Location block of a script
Finally I tried making a Location /cgi-bin/contact.cgi block in an attempt
to get as close to the conditions under which the last script output with a
non-zero length was seen. No help!
Scripts that do a redirect using the same send_response routine as above,
show log entries like 302 771, although $body contained just a few bytes.
So my question is: what do I need to do, to make Apache hand off the output
from the script to mod_gzip properly, and (far less important) show the
proper length in the log?
Thanks to anyone who can help,
Craig MacKenna
Los Gatos, CA
408-353-5037
Re: Can't locate ../Functions/db.pl in @INC
I'll give this a shot, seeing as no one seemed to have answered: In your pl files you can try including something like: use lib qw(directory containing module directories); Example: use lib qw(/usr/local/apache2/perl); In my config I have PerlRequire /usr/local/apache2/perl/startup.pl which contains: use lib qw(/usr/local/apache2/perl); 1; Not sure if this will work with your version of apache. Cheers, Craig On Tue, 26 Oct 2004 23:25:49 -0700 (PDT), mahboobeh soleimani [EMAIL PROTECTED] wrote: Hi every body. I have a apache 1.3.31 and mod_perl 1.28 and used Files *.pl SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On /Files in http.conf but when i enter: perl /root/prelude/piwi/test/index.pl i can see this error : Can't locate ../Functions/db.pl in @INC (@INC contains: /usr/lib/perl5/5.8.1/i38sr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/d-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perrl5/5.8.1 .) at /root/prelude/piwi/test/index.pl line 3. also i can not view my index.pl by Mozilla could you please guide me? regards. M.S. __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail -- 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 -- Primer: Shane Carruth: It's about some engineers that are trying to build a device that degrades gravity. They find out it has unexplainable properties. Hilarity ensues. -- 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: Win32 build problems libapreq2-2.04_03-dev
After updating both Apache2 and mod_perl on the W2K Server, there are still
some problems in building libarpeq2-2.04_03-dev on Win32.
Current software levels are:
Apache/2.0.50 (Win32) mod_perl/1.99_16 Perl/v5.8.4 Server
When invoking 'nmake perl_glue', 'nmake perl_test', or nmake perl_install
each will return the same error message. Nmake correctly detects that
Apache2 is installed at 'E:\Apache2'.
.
.
.
nmake perl_glue
writing...xs//Makefile.PL
writing...xs/Apache/Makefile.PL
[ info] generating script t/TEST
Can't find the mod_perl include dir (reason: path D:\Apache2\include doesn't
exi
st) at E:/Perl/site/lib/Apache2/Apache/Build.pm line 1715.
NMAKE : fatal error U1077: 'E:\Perl\bin\perl.exe' : return code '0x2'
If this error message is indeed attempting to find files in the directory,
'D:\Apache2\include', it won't because the directory doesn't exist. Its not
clear to me where the build process is picking up the reference to
'D:\Apache2\include'.
Scanning both the directories 'E:\Perl' and 'E:\Apache2' for 'D:\Apache2',
the file
'E:\Perl\site\lib\Apache2\auto\libaprext\extralibs.ld' was found to contain
references to 'D:\Apache2\lib'. After correcting the invalid references, the
problem still exists.
Windows XP Pro is having the exact same problem too.
Thanks, Craig
-Original Message-
From: Randy Kobes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 21:15
To: Craig Dayton
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Win32 build problems libapreq2-2.04_03-dev
On Wed, 1 Sep 2004, Craig Dayton wrote:
Hi Randy,
For the Windows 2000 Server system its running mod_perl/1.99_14, so
this explains the missing file problem. The current
mod_perl will get
built on this system.
Great - that should resolve that problem ...
I'm not sure what the problem is here - all of the Apache
references
above use E:\ as the drive, which appears correct. When you did the
'perl Makefile.PL', did a confirmation come up asking you which
Apache to use? If so, was it the correct one, including the drive
letter?
Yes Yes.
I tried 'perl Makefile.PL' and it found the correct Apache2 location
and I responded 'yes' to the prompt. Also, I tried 'perl Makefile.PL
--with-Apache2=E:/Apache2'. In both cases its trying to find Apache
on a another drive. In the first instance, it was expecting Apache2
on drive Z: which was a valid network drive. After disconnecting the
network drive Z:, the second attempt was expecting Apache to be on
drive D: (CD-ROM).
I take it this is at the
nmake test
stage? I can't see why it would be looking in different
drives at this point; it's already found Apache ...
[ debug] can't figure out Apache revision, from string:
'', using
a non-existin g revision 0
Its interesting that an empty string is referenced in the output
above.
Do you have an Apache/TestConfigData.pm somewhere on your system,
either in the main Perl tree or under a .apache-test
directory under,
eg, C:\ or E:\? If so, does it help if you move it out of
the way and
run the tests again?
No. TestConfigData.pm is only located at 'E:\Perl\site\lib\Apache\'.
Looking at this module, I see the following:
$Apache::TestConfigData::vars = {'httpd' =
'\Apache2\bin\Apache.EXE',}; I tried changing this to
'E:\Apache2\bin\Apache.EXE'. This didn't help.
What if you tried moving this file completely away?
I tried adding 'E:\Apache2\bin' to the Path environmental variable
just see if that might help. It didn't. The 'nmake test' is still
failing for the same apparent reason of not being able to resolve
Apache2's location. Also, I find it interesting that
apxs.bat failed
its 3 query attempts too.
Thanks, Craig
The problem with apxs.bat on Win32 is related to something
that changed recently in Apache-Test; I haven't been able to
trace why these warnings are arising ...
To try to eliminate one possibility, what happens if you
move $APACHE2\bin\apxs.bat somewhere outside of the PATH,
and then do
nmake perl_glue
nmake perl_test
That should work - it's only the
nmake test
target that requires apxs.
Also, there's a file $APACHE2\build\config_vars.mak with
various settings used by apxs - for those that reference a
drive, is the letter correct?
--
best regards,
randy
--
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
--
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::DB ported to mp2
Frank, I get the same error exact error with Apache::DB 0.06. Compress-Zlib-1.33 has compiled installed successfully just now and it appears to be using XS. VS .Net (prior version) is generating the same error too. Note: The option '-Gf' was changed to '-GF' in the makefile because the compiler didn't like '-Gf'. I don't mind doing compile tests, if you need that support. -Craig -Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 08:17 To: Craig Dayton Cc: [EMAIL PROTECTED] Subject: Re: Apache::DB ported to mp2 Hi Craig, I didn't have to make any changes to the XS code on this module to port it to mp2. Can you do me a favor and grab Apache::DB 0.06 and see if you get the same error? Not being a Windows user or even having access to a Windows installation with a compiler, this is going to be difficult for me to track down. I'm assuming you've built other CPAN modules that have C/XS components on this system with that compiler before without problems? Does anyone know if XS generates C code that .net 2003 can compile? - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - On Thu, 8 Apr 2004 19:39:25 -0700 Craig Dayton [EMAIL PROTECTED] wrote: Hi Frank, Thanks for the Update. In compiling with 'VS .Net 2003', the error shown below is generated. -Craig E:\Perl\cpan\build\Apache-DB-0.07nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl -c-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_ST RICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1-DVERSION=\0.07\ -DXS_VERSION=\ 0.07\ -IE:\Perl\lib\CORE DB.c DB.c DB.xs(55) : error C2065: 'SIGINT' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. -Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 11:42 To: [EMAIL PROTECTED] Subject: Apache::DB ported to mp2 Hi Everyone, I've ported Apache::DB to work with mp1 and mp2. I've done some initial testing, but would appreciate anyone interested to give it a whirl. Let me know if you run into any problems. Note that I haven't ported Apache::DProf or Apache::SmallProf yet, but plan on doing those in the next few weeks as time permits. You can grab it at: http://cpan.org/authors/id/F/FW/FWILES/Apache-DB-0.07.tar.gz Once I've done a bit more testing and get the other modules ported it will be released on CPAN for general consumption. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.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: Apache::DB ported to mp2
Thanks Randy, You got it. After adding '#define SIGINT 2' to DB.xs, it compiled just fine. -Craig -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 17:15 To: Craig Dayton Cc: 'Frank Wiles'; [EMAIL PROTECTED] Subject: RE: Apache::DB ported to mp2 On Thu, 8 Apr 2004, Craig Dayton wrote: Hi Frank, Thanks for the Update. In compiling with 'VS .Net 2003', the error shown below is generated. E:\Perl\cpan\build\Apache-DB-0.07nmake cl -c-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\0.07\ -DXS_VERSION=\ 0.07\ -IE:\Perl\lib\CORE DB.c DB.c DB.xs(55) : error C2065: 'SIGINT' : undeclared identifier This needs the definition of SIGINT in signal.h on Win32. For some reason just including signal.h results for me in a syntax error, probably because of some other header files also being needed, but as a workaround, putting in #define SIGINT 2 in DB.xs will allow it to compile. -- best regards, randy kobes -- 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::DB ported to mp2
Hi Frank, Thanks for the Update. In compiling with 'VS .Net 2003', the error shown below is generated. -Craig E:\Perl\cpan\build\Apache-DB-0.07nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl -c-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_ST RICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1-DVERSION=\0.07\ -DXS_VERSION=\ 0.07\ -IE:\Perl\lib\CORE DB.c DB.c DB.xs(55) : error C2065: 'SIGINT' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. -Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 11:42 To: [EMAIL PROTECTED] Subject: Apache::DB ported to mp2 Hi Everyone, I've ported Apache::DB to work with mp1 and mp2. I've done some initial testing, but would appreciate anyone interested to give it a whirl. Let me know if you run into any problems. Note that I haven't ported Apache::DProf or Apache::SmallProf yet, but plan on doing those in the next few weeks as time permits. You can grab it at: http://cpan.org/authors/id/F/FW/FWILES/Apache-DB-0.07.tar.gz Once I've done a bit more testing and get the other modules ported it will be released on CPAN for general consumption. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.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 -- 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
cannot find -lperl?
Has anyone gotten this type of error when installing modperl: /usr/bin/ld: cannot find -lperl? -mod_perl-1.28 -apache_1.3.29 clm __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
/usr/bin/ld: cannot find -lperl(More Info.)
Better yet here's the complete error message: commmand: perl Makefile.PLAPACHE_SRC=/home/cmcmillo/src/apache_1.3.29 DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 error: Error Output for sanity check cd ..; cc -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -D_REENTRANT -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DNO_DL_NEEDED -D_REENTRANT -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 `./apaci` -I. -I/usr/lib/perl/5.8.2/CORE-o helpers/dummy helpers/dummy.c -lm -lcrypt -rdynamic -L/usr/local/lib /usr/lib/perl/5.8.2/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl/5.8.2/CORE -lperl -ldl -lm -lpthread -lc -lcrypt /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make: *** [dummy] Error 1 = End of Error Report = __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: /usr/bin/ld: cannot find -lperl(More Info.)
Sorry about just responding to you Stas and not the list(still getting use to that). Anyway yes, your suggestions below worked well. Thanks again. clm --- Stas Bekman [EMAIL PROTECTED] wrote: Craig McMillon wrote: Here it is Thanks perl -V Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration: Platform: osname=linux, osvers=2.4.22-xfs+ti1211, archname=i386-linux-thread-multi uname='linux kosh 2.4.22-xfs+ti1211 #1 sat oct 25 10:11:37 est 2003 i686 gnu what is kosh? some new distro? 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.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.2 gnulibc_version='2.3.2' find a file called libperl.so.5.8.2 probably living under /usr/local/lib/perl find /usr/local/lib/perl | grep libperl.so.5.8.2 or /usr/lib/perl5, or anywhere else. I can't figure out where they put it. let's say it's: /usr/local/lib/perl/i386-linux/CORE/libperl.so.5.8.2 add a symlink to it (or check whether it exists already): ln -sf /usr/local/lib/perl/i386-linux/CORE/libperl.so.5.8.2\ /usr/local/lib/perl/i386-linux/CORE/libperl.so Now it may find it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
