Re: changing apache process name?
On Tue 01 Sep 2009, Sebastiaan Hoogeveen wrote: Not sure if this would fix your problem, but you can just set $0 from within the mod_perl module to whatever you'd like to show up in the process list, just as with a regular perl script. It probably depends on the OS you're running whether this works as it should; I can confirm that it works on Linux. This should work in mod_perl as well. Perl 5.8.0 had a bug that prevented it. Hence the Sys::Proctitle module. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
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: Fwd: Undefined symbol Perl_pad_sv building mp2
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. 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 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. -- Michael Peters Plus Three, LP
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: Software caused connection abort at
Hi We recently started seeing this appearing in our logs as well, and I'm not sure what's causing it. We didn't change our software in any way that I can see would have caused this to start happening, so it's quite odd. Did you work out what was causing it? Rob - Original Message - From: Jim j...@netrition.com To: modperl@perl.apache.org Sent: Saturday, August 01, 2009 1:32 PM Subject: Software caused connection abort at I recently upgraded software on my apache servers so that I am now running: Apache/2.2.3 MOD_PERL = mod_perl/2.0.4 MOD_PERL_API_VERSION = 2 perl 5.8.8 Operating system: Red Hat Linux 2.6.18-128.2.1 In my web server error logs I started seeing messages such as: Software caused connection abort at 'some_module_name.pm' line 'some_line_number'. All the modules that appear in these messages give me the impression it is likely mod_perl scripts that are causing them. My mod_perl scripts are configured as such: Location /cgi/some_mod_perl_script.cgi SetHandler perl-script PerlHandler ModPerl::PerlRun Options ExecCGI PerlSendHeader On /Location The line numbers in the error message seem to all point to lines of code in modules that are doing output to stdout. Any thoughts on the circumstances that might produce those errors? -- Jim Albert
