Re: Perl Run and Load Average
Hi Dale, Assuming your CGI scripts aren't doing strange things, liking hanging around after the session has closed and doing clean-up work, you might check your httpd.conf settings on the number of threads and requests per threads. Its possible that your httpd threads are short-lived and restarting more often which now requires a lot more work to start since Perl is being loaded each time - just an idea. MaxRequestsPerChild 1000# if this were too low, say 10 or 50, you would probably create more load # If these were out of wack somehow, it could possibly create some # unusual load conditions MaxSpareServers 20 MinSpareServers 5 I have this setting on my httpd.conf: IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 ServerLimit 300 MaxClients 300 MaxRequestsPerChild 1000 /IfModule Any idea on how can I tweak this setting? I would also run top -d 1 while your webserver is running without mod_perl to see what scripts are causing the load. Do you have a database running on the same system? Do you know if it might be doing more work? The database server is on another machine, but I think I should try to preload DBI module, and see the result. I just noticed that the load was going down after I restarted httpd. Is this because of my scripts have bugs? I think I have some DBI connect without disconnect in my scripts. I will try to fix this and see how is the result.
Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources
On Yesterday at 11:17am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB Is it possible that you have an old install and it gets loaded SB instead? Can you try nuking any preinstalled mod_perl libs? SB Hi Stas, This will be a long email (I think you're probably used to looking at long emails already :-). Thanks for your helpful suggestions and wonderful support again. I have made some progress and here are my findings. Here's what I did. Based upon your suspicion that the tests were failing because of some preinstalled mod_perl libs (true: the system had mod_perl 1.99_08 installed), I did a local perl install: 1. Installed xstow to make life easier when installing/removing files 2. Installed perl in ~/stow/perl-5.8.0 3. Compiled mod_perl against locally installed perl Experience with 1.99_09: In the first batch of test, I had one failure for filter/in_bbs_msg.t. -- begin - filter/in_bbs_msg# connecting to localhost.localdomain:8535 server side has failed (response code: 404), see t/logs/error_log for more details dubious Test returned status 29 (wstat 7424, 0x1d00) *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) -- end - Running t/TEST -verbose filter/in_bbs_msg.t, I got the following from t/logs/error_log -- begin - [Thu Jun 05 10:10:40 2003] [error] [client 127.0.0.1] File does not exist: /home/haroon/src/build/mod_perl-1.99_09/t/htdocs/input_filter.html -- end - Experience with 1.99_10-dev (up to date with CVS till yesterday): = The first batch of tests passes 100%, so the filter/in_bbs_msg.t from 1.99_09 is fixed. However, ModPerl-Registry tests fail with: Failed Test Stat Wstat Total Fail Failed List of Failed --- redirect.t 22 100.00% 1-2 special_blocks.t 122 16.67% 6 10 Running t/TEST -verbose redirect.t special_blocks.t gave me the following output: -- begin - /servers/httpd-2.0.44-pl/bin/httpd -d /home/haroon/src/build/modperl-2.0/ModPerl-Registry/t -f /home/haroon/src/build/modperl-2.0/ModPerl-Registry/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.44 (prefork MPM) waiting for server to start: . waiting for server to start: ok (waited 3 secs) server localhost.localdomain:8529 started redirect..1..2 # testing : test redirect: existing target # expected: ok # received: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN # htmlhead # title302 Found/title # /headbody # h1Found/h1 # pThe document has moved a href=http://localhost.localdomain:8529/registry/basic.pl;here/a./p # /body/html not ok 1 # Failed test 1 in redirect.t at line 16 # testing : test redirect: non-existing target # expected: 404 # received: 302 not ok 2 # Failed test 2 in redirect.t at line 27 FAILED tests 1-2 Failed 2/2 tests, 0.00% okay special_blocks1..12 # testing : ModPerl::PerlRun is running BEGIN blocks on the first req # expected: begin ok # received: begin ok ok 1 # testing : ModPerl::PerlRun is running BEGIN blocks on the second req # expected: begin ok # received: begin ok ok 2 # testing : ModPerl::PerlRun is running END blocks on the first req # expected: end ok # received: end ok ok 3 # testing : ModPerl::PerlRun is running END blocks on the second req # expected: end ok # received: end ok ok 4 # testing : ModPerl::Registry is running BEGIN blocks on the first req # expected: begin ok # received: begin ok ok 5 # testing : ModPerl::Registry is not running BEGIN blocks on the second req # expected: # received: undef not ok 6 # Failed test 6 in special_blocks.t at line 70 # testing : ModPerl::Registry is running END blocks on the first req # expected: end ok # received: end ok ok 7 # testing : ModPerl::Registry is running END blocks on the second req # expected: end ok # received: end ok ok 8 # testing : ModPerl::RegistryBB is running BEGIN blocks on the first req # expected: begin ok # received: begin ok ok 9 # testing : ModPerl::RegistryBB is not running BEGIN blocks on the second req # expected: # received: undef not ok 10 # Failed test 10 in special_blocks.t at line 70 fail #2 # testing : ModPerl::RegistryBB is running END blocks on the first req # expected: end ok # received: end ok ok 11 # testing : ModPerl::RegistryBB is running END blocks on the second req # expected: end ok # received: end ok ok 12 FAILED tests 6, 10 Failed 2/12 tests, 83.33% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- redirect.t 22 100.00% 1-2 special_blocks.t
Re: Perl Run and Load Average
On Thu, 2003-06-05 at 09:31, Batara Kesuma wrote: I just noticed that the load was going down after I restarted httpd. Is this because of my scripts have bugs? I think I have some DBI connect without disconnect in my scripts. I will try to fix this and see how is the result. Are your scripts using up all the available memory and sending you into swap? That will shoot the load up quickly, and go away when you restart. As Stas mentioned, you should try to run Registry instead of PerlRun if you can. - Perrin
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 03:35, Dennis G. Allard wrote: (BTW, my more general goal is to have shared memory across multiple Apache threads as part of implementing sessions so that I can avoid doing a database write at every HTTP request just to save session IDs.) Hmmm, save session IDs? Why aren't you just putting those in a cookie or in the URLs? If you meant to say session data rather than IDs, there are several good ways to do this, and IPC::ShareLite isn't one of them. It's too slow. If this is for a single machine, try either IPC::MM or MLDBM::Sync. If it's for a cluster, it's pretty hard to beat MySQL. - Perrin
Truncated POST at 8192 bytes
Hi All, Looks like mod_perl is discarding everything past the first 8192 bytes from POST requests. mod_perl 1.99 Perl 5.8.0 Apache 2.0.40 All latest RPMs for Redhat 9. There are some very related looking messages in the archives, but they seem to pertain to earlier version of mod_perl, and I'm unable to come up a working solution. I put together a dummy test script: --- #!/usr/bin/perl read (STDIN, $in, $ENV{'CONTENT_LENGTH'}); print Content Length: $ENV{'CONTENT_LENGTH'}\n\nP\n; print Data Input: $in\n\nP\n; print Data Length: , length $in; --- Read inbound and spit it back out, nice and simple. When I set Apache directives on the directory where I'm running it to: SetHandler cgi-script and submit a request that I've been having trouble with, I get back Data Length: 197745 when I change the Apache directives on the test directory to: SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders I get back Data Length: 8192 This is consistent regardless of what I POST or where I POST from. Any assistance would be greatly appreciated - it's been a long road to come up with even this much information. Many thanks, -- Mick Szucs [EMAIL PROTECTED] Onramp Network Services Inc.
problem with pulling variables from mod_ssl
I'm trying to write an apache authentication module that uses client certificates for authentication. Basically, all I'm trying to do is use what mod_ssl does for cert verification, and then set REMOTE_USER. I wrote to the list last week about a segfault, which was resolved thanks to the help you guys gave me. Now I am stuck with a problem that is likely a logic error on my part, but I have a feeling that my problem stems from a misunderstanding of how apache is supposed to work. Since my module is very short, I'll include it in this email, along with the relevant contents of my error_log, in the hopes that someone might be able to point me in the right direction. Thanks! ---my module, AuthNx509.pm package Apache::AuthNx509; use strict; use Apache::Constants qw(:common); use Text::ParseWords qw(quotewords); use Apache::Log (); sub handler { my $r = shift; my $c = $r-connection; my $log = $r-log; my $certcomponent = $r-dir_config('CertComponent') || 'SSL_CLIENT_S_DN_O'; my $certcompvalue = $r-dir_config('CertComponentValue') || 'University of Wisconsin'; my $usercomponent = $r-dir_config('RemoteUserCertComponent') || 'SSL_CLIENT_S_DN_CN'; my $uri = $r-uri; return unless $r-is_main(); my $subr = $r-lookup_uri($uri); my $apachecertcomp = $subr-subprocess_env($certcomponent); $log-notice(hello: $apachecertcomp); if ($apachecertcomp eq $certcompvalue) { $log-notice($certcompvalue good); $c-user = $r-subprocess_env-{$usercomponent}; $log-notice($c-user logged in successfully); return OK; } $log-notice(cert no good: $r-subprocess_env-{$certcomponent}); my $reason = Client Cert not in correct form; $r-note_basic_auth_failure; $r-log_reason($reason, $r-filename); return DECLINED; } 1; __END__ -- error log data: Thu Jun 5 14:57:11 2003] [notice] [client 128.104.16.134] hello: [Thu Jun 5 14:57:11 2003] [notice] [client 128.104.16.134] cert no good: Apache=SCALAR(0x8100308)-subprocess_env-{SSL_CLIENT_S_DN_C} [Thu Jun 5 14:57:11 2003] [error] access to /var/www/html/test failed for 128.104.16.134, reason: Client Cert not in correct form [Thu Jun 5 14:57:13 2003] [notice] [client 128.104.16.134] hello: [Thu Jun 5 14:57:13 2003] [notice] [client 128.104.16.134] cert no good: Apache=SCALAR(0x8100308)-subprocess_env-{SSL_CLIENT_S_DN_C} [Thu Jun 5 14:57:13 2003] [error] access to /var/www/html/test failed for 128.104.16.134, reason: Client Cert not in correct form [Thu Jun 5 14:57:13 2003] [crit] [client 128.104.16.134] configuration error: couldn't check user. No user file?: /test/ configuration data (in a Directory statement): SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE} = 128 # Force clients to use HTTPS RewriteEngineon RewriteCond %{HTTPS} !=on RewriteRule .* - [F] AuthName Test AuthType Basic PerlAuthenHandler Apache::AuthNx509 PerlSetVar CertComponent SSL_CLIENT_S_DN_C PerlSetVar CertComponentValue US PerlSetVar RemoteUserCertComponent SSL_CLIENT_S_DN_CN require valid-user Any ideas would be most appreciated. Thanks again! --Ryan
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 15:55, Dennis G. Allard wrote: MySQL ShmySQL. A database that didn't have transactions until last year and still has no stored procedures Uh, we're talking about session data here, right? Basically a remotely accessible hash? Stored procedures have no place there, and transactions don't have much of one either, as evidenced by the fact that many people simply use files for their session storage. With a simple table (probably just ID, DATA, and TIMESTAMP) and simple insert/update/select operations, MySQL pretty much blows everything else away. That's why I recommend it for this use. If you already have another database, that's fine too. If your OS has good NFS or SMB available, you can use MLDBM::Sync over that. You have to be certain that locking is well-supported on your OS though, and I doubt it will be faster than MySQL. BTW, I wanted to use Apache::Session or CGI::Session but had some problems with each, possibly related to my newness with Apache 2/mod_perl 2/compat/whatever. I haven't used either on mod_perl 2, but there's no reason why they shouldn't work. Neither of them makes any use of mod_perl or the Apache API. If you post more information about the problems, we may be able to fix them. So, I've decide to implement my own sessions for now, just for the hell of it, while I wait for Apache 2 dust to settle or land a project where I am forced to decipher the possibilities better. You could also simply use mod_perl 1. It is still actively maintained and remains a good choice for new development. - Perrin
install mod_perl2 under Redhat 8
HiHow to install latest mod_perl 2 under redhat 8, i can'tfind mod-perl-1.99_09 RPM at http://perl.apache.org/download/index.htmlthx
Re: How tell what version of mod_perl is installed?
Hmmm. No one has actually answered the question, although I am getting all kinds of advice... (-; ... On Thu, 2003-06-05 at 01:42, Stas Bekman wrote: Thomas Klausner wrote: Hi! On Don, Jun 05, 2003 at 12:35:37 -0700, Dennis G. Allard wrote: I am running Red Hat 8.0, Apache/2.0.40. AFAIK, mod_perl 1.x won't run with Apache 2.0, so I'm quite sure you're running mod_perl 2 (which comes shipped with Red Hat 8) But Dennis, you don't want the version that comes with RH8, it's 1 year old! get 1.99_09 from here: http://perl.apache.org/download/index.html Thanks for that information, Stas. I'll take that to mean 'yes', I do have mod_perl 2.0 (although, per my previous post of my `strings /usr/lib/httpd/modules/mod_perl.so` output, my version is (I guess) 1.99_05-dev, which, you have to admit, does not look like '2.0'. Please note, though, one of my goals in life is to rely on my software providers to do the work of providing me with a stable, tested, updatable OS and associated tools. If I download 'out of band' updates, then I can no longer rely on Red Hat's network update tool, for example. With all due respect for your fine work, which is awesome, there are application developers such as myself out there who simply don't have time to track the bleeding edge except when absolutely forced to do so (which sometimes does happen). My heuristic is that I intentionally stay behind the curve. I don't use Oracle 9 yet, for example. My current need for mod_perl 2.0 is not critical, so I will give it another year or so before I dig in and make the (substantial) effort of coverting entirely to it. to check the version you can do: /home/stas perl-blead -Mmod_perl -le 'print mod_perl-VERSION' 1.2701 /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION' 1.9910 As you can see, I have both. 1.9910 is mod_perl-2.0-tobe (but currently only 1.9909 is available, 1.9910 is a cvs version). Bummer, I don't have perl-blead and there are only 17 references to it in the entire history of Dejanews, none that seem to point to a download... [EMAIL PROTECTED] httpd]# perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION' bash: perl-blead: command not found [EMAIL PROTECTED] httpd]# [EMAIL PROTECTED] httpd]# whereis perl-blead perl-blead: [EMAIL PROTECTED] httpd]# locate perl-blead I could take time to find/download perl-blead, but hey, gotta go earn some money! (-; Outta here for now. __ 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 -- Dennis G. Allard telephone: 1.310.399.4740 Ocean Park Software http://oceanpark.com
Re: How tell what version of mod_perl is installed?
Hi! On Thu, Jun 05, 2003 at 01:37:59PM -0700, Dennis G. Allard wrote: Please note, though, one of my goals in life is to rely on my software providers to do the work of providing me with a stable, tested, updatable OS and associated tools. If I download 'out of band' updates, then I can no longer rely on Red Hat's network update tool, for example. With all due respect for your fine work, which is awesome, there are application developers such as myself out there who simply don't have time to track the bleeding edge except when absolutely forced to do so (which sometimes does happen). The latest Red Hat comes with Apache 2 (because Apache 2 is quite stable). Unfortunatly mod_perl 2.0 is /not/ that finished (Sorry Stas..). But because Red Hat wants to provide mod_perl to its Users, they included the Beta Version in their distro. So blame them ... /home/stas perl-blead -Mmod_perl -le 'print mod_perl-VERSION' 1.2701 /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION' 1.9910 Bummer, I don't have perl-blead and there are only 17 references to it in the entire history of Dejanews, none that seem to point to a download... You don't need perl-blead (which is probably Stas' install of the latest unstable Perl version) This will do the same job: % perl -Mmod-perl -le 'print mod_perl-VERSION' -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 13:08, Perrin Harkins wrote: On Thu, 2003-06-05 at 15:55, Dennis G. Allard wrote: MySQL ShmySQL. A database that didn't have transactions until last year and still has no stored procedures Uh, we're talking about session data here, right? Basically ... My point about MySQL was a general comment for why I did not use it (in the past), not just about sessions. Your suggestions for tools to implement sessions are all sound. Cheers, Dennis -- Dennis G. Allard [EMAIL PROTECTED] http://oceanpark.com
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 13:37, Thomas Klausner wrote: Hi! On Thu, Jun 05, 2003 at 01:37:59PM -0700, Dennis G. Allard wrote: [In reply to Stas] Please note, though, one of my goals in life is to rely on my software providers to do the work of providing me with a stable, tested, updatable OS and associated tools. If I download 'out of band' updates, then I can no longer rely on Red Hat's network update tool, for example. With all due respect for your fine work, which is awesome, there are application developers such as myself out there who simply don't have time to track the bleeding edge except when absolutely forced to do so (which sometimes does happen). The latest Red Hat comes with Apache 2 (because Apache 2 is quite stable). Unfortunatly mod_perl 2.0 is /not/ that finished (Sorry Stas..). But because Red Hat wants to provide mod_perl to its Users, they included the Beta Version in their distro. And once mod_perl 2.0 become stable, Red Hat will ship it, and those having my philosophy will begin developing with it! So blame them ... No blame needed. Everyone is doing a good job as fast as they can. /home/stas perl-blead -Mmod_perl -le 'print mod_perl-VERSION' 1.2701 /home/stas perl-blead -MApache2 -Mmod_perl -le 'print mod_perl-VERSION' 1.9910 Bummer, I don't have perl-blead and there are only 17 references to it in the entire history of Dejanews, none that seem to point to a download... You don't need perl-blead (which is probably Stas' install of the latest unstable Perl version) This will do the same job: % perl -Mmod-perl -le 'print mod_perl-VERSION' Bummmer, that does not work either for me on Red Hat 8.0: [EMAIL PROTECTED] httpd]# perl -Mmod-perl -le 'print mod_perl-VERSION' Can't locate mod.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .). BEGIN failed--compilation aborted. I'm new to this list. Thanks for everyone's advice. -- Dennis G. Allard telephone: 1.310.399.4740 Ocean Park Software http://oceanpark.com
Re: How tell what version of mod_perl is installed?
Hi! On Thu, Jun 05, 2003 at 01:56:58PM -0700, Dennis G. Allard wrote: You don't need perl-blead (which is probably Stas' install of the latest unstable Perl version) This will do the same job: % perl -Mmod-perl -le 'print mod_perl-VERSION' Bummmer, that does not work either for me on Red Hat 8.0: Sorry, typo: it should say -Mmod_perl instead of -Mmod-perl, i.e.: % perl -Mmod_perl -le 'print mod_perl-VERSION' -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 16:37, Dennis G. Allard wrote: Hmmm. No one has actually answered the question, although I am getting all kinds of advice... (-; ... Thomas Klausner said that mod_perl 2 only runs on apache 2 and mod_perl 1 only runs on apache 1. He is correct. Red Hat gave you an early version of mod_perl 2 because they gave you apache 2. I'll take that to mean 'yes', I do have mod_perl 2.0 (although, per my previous post of my `strings /usr/lib/httpd/modules/mod_perl.so` output, my version is (I guess) 1.99_05-dev, which, you have to admit, does not look like '2.0'. The 2.x branch has not reached an official release yet. It is still basically considered beta. When it is officially released, it will be 2.0. Please note, though, one of my goals in life is to rely on my software providers to do the work of providing me with a stable, tested, updatable OS and associated tools. If I download 'out of band' updates, then I can no longer rely on Red Hat's network update tool, for example. If you want to use bleeding edge software, you do have to keep up. My heuristic is that I intentionally stay behind the curve. In that case, you should use apache 1 and mod_perl 1. My current need for mod_perl 2.0 is not critical, so I will give it another year or so before I dig in and make the (substantial) effort of coverting entirely to it. Most of us find that it's pretty easy to convert to mod_perl 1, provided you have clean Perl code to begin with. Bummer, I don't have perl-blead Bleedperl (aka perl-blead) is the name for the unreleased development version of Perl. You don't need it. - Perrin
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 13:53, Thomas Klausner wrote: Sorry, typo: it should say -Mmod_perl instead of -Mmod-perl, i.e.: % perl -Mmod_perl -le 'print mod_perl-VERSION' THANKS! (I should have caught that one myself, for crying out loud). For the sake of completeness: [EMAIL PROTECTED] root]# uname -a Linux oceanpark.com 2.4.20-18.8 #1 Thu May 29 07:20:39 EDT 2003 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] root]# cat /etc/issue Red Hat Linux release 8.0 (Psyche) Kernel \r on an \m [EMAIL PROTECTED] root]# perl -Mmod_perl -le 'print mod_perl-VERSION' 1.9905 Cheers, Dennis -- Dennis G. Allard telephone: 1.310.399.4740 Ocean Park Software http://oceanpark.com
Re: How tell what version of mod_perl is installed?
Hi there, On 5 Jun 2003, Dennis G. Allard wrote: Hmmm. No one has actually answered the question, although I am getting all kinds of advice... (-; ... It's been good advice. If the question to which you refer is the one in the subject line, then one answer is look in the error log. Apache tells you when it starts. It's generally about the first thing it says. Your error log is defined in your Apache configuration file (probably httpd.conf) in a line that starts ErrorLog You could also take a look at http://perl.apache.org/docs/2.0/user/intro/start_fast.html which has an example of the output in the error log from a server when it's started. If your question isn't the one in the subject line, please accept my apologies - I haven't been following this thread closely. Feel free to ask it again if it hasn't yet been answered. There's more FM to R if you work with Apache/mod_perl 1.x - if you're going to be doing a lot of work for a commercial application and you don't want to be involved in the mod_perl 2.x development, and you're going to want lots more people around to hold your hand, then that's what I'd recommend. There are good books too. Buy them. Read them. You're an exceptional individual if you can absorb it all the first time through, so read them again. Oh, heck. More advice. 73, Ged.
Re: mod_perl2 rpm for Redhat 8
[moving the thread to the appropriate list and adjusting the subject] Thomas Klausner wrote: Hi! On Don, Jun 05, 2003 at 02:53:52 +0400, Egor Korablev wrote: This list is for discussing mod_perl documentation issus. For general mod_perl Problem, use the mod_perl users list: http://perl.apache.org/maillist/modperl.html How to install latest mod_perl 2 under redhat 8, i can't find mod-perl-1.99_09 RPM at http://perl.apache.org/download/index.html mod_perl is only provided as a source tarball. Pre-compiled binaries are provided by third parties. Try to google for mod_perl 1.99 rpm Or download the sources and install them. Egor, I think you can find the latest rpm in the redhat's rawhide repository, similar to the mandrake's cooker. __ 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
Re: Perl Run and Load Average
Batara Kesuma wrote: I will try to move all standard modules to startup.pl. Do I need to delete the standard modules from the scripts after I moved them to startup.pl? I mean, after I moved: use MyModule; to startup.pl, do I need to delete it from the scripts? Or Perl Run will automatically figure out that it has already been loaded and simply ignore the one in the scripts? No, no, you shouldn't delete anything at all. Perl uses the %INC hash to track what was loaded already. Perhaps it'll benefit you to read a good perl book or at least this document: http://perl.apache.org/docs/general/perl_reference/perl_reference.html I have this setting on my httpd.conf: IfModule prefork.c StartServers 8 MinSpareServers5 MaxSpareServers 20 ServerLimit 300 MaxClients 300 MaxRequestsPerChild 1000 /IfModule Any idea on how can I tweak this setting? Please read: http://perl.apache.org/docs/1.0/guide/performance.html in particular http://perl.apache.org/docs/1.0/guide/performance.html#Performance_Tuning_by_Tweaking_Apache_Configuration Since you are running prefork mpm, most of these mod_perl 1 notes apply to your mod_perl 2 setup. I would also run top -d 1 while your webserver is running without mod_perl to see what scripts are causing the load. Do you have a database running on the same system? Do you know if it might be doing more work? The database server is on another machine, but I think I should try to preload DBI module, and see the result. I just noticed that the load was going down after I restarted httpd. Is this because of my scripts have bugs? I think I have some DBI connect without disconnect in my scripts. I will try to fix this and see how is the result. You can always monitor this using the database tools. Also consider using Apache::DBI. it's all the document I've mentioned above. __ 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
Re: Truncated POST at 8192 bytes
Mick Szucs wrote: Hi All, Looks like mod_perl is discarding everything past the first 8192 bytes from POST requests. mod_perl 1.99 Perl 5.8.0 Apache 2.0.40 All latest RPMs for Redhat 9. The latest version that we carry (1.99_09) has this problem fixed: http://perl.apache.org/download/index.html If the problem persists or in any future bug reporting please make sure to submit a complete bug report as explained here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Thanks. __ 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
Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources
Haroon Rafique wrote: On Yesterday at 11:17am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB Is it possible that you have an old install and it gets loaded SB instead? Can you try nuking any preinstalled mod_perl libs? SB Hi Stas, This will be a long email (I think you're probably used to looking at long emails already :-). Thanks for your helpful suggestions and wonderful support again. ;) I have made some progress and here are my findings. Here's what I did. Based upon your suspicion that the tests were failing because of some preinstalled mod_perl libs (true: the system had mod_perl 1.99_08 installed), I did a local perl install: 1. Installed xstow to make life easier when installing/removing files 2. Installed perl in ~/stow/perl-5.8.0 3. Compiled mod_perl against locally installed perl Great. So that explains why I had a flash of this problem and then couldn't reproduce it. Once the current problems are resolved it'd be nice to track that problem. I believe that the cause is a wrong @INC. So if you can keep the old setup untouched that would be great. We are now discussing adding a bootstrap checking on all mod_perl libraries. We have too many problem reports just because old libraries kick in. Experience with 1.99_09: In the first batch of test, I had one failure for filter/in_bbs_msg.t. -- begin - filter/in_bbs_msg# connecting to localhost.localdomain:8535 server side has failed (response code: 404), see t/logs/error_log for more details dubious Test returned status 29 (wstat 7424, 0x1d00) *** server localhost.localdomain:8529 shutdown !!! error running tests (please examine t/logs/error_log) -- end - Running t/TEST -verbose filter/in_bbs_msg.t, I got the following from t/logs/error_log -- begin - [Thu Jun 05 10:10:40 2003] [error] [client 127.0.0.1] File does not exist: /home/haroon/src/build/mod_perl-1.99_09/t/htdocs/input_filter.html -- end - Yup, this one is resolved: cvs log t/filter/in_bbs_msg.t ... revision 1.4 date: 2003/05/11 22:59:21; author: stas; state: Exp; lines: +2 -9 - get rid of the http://hostname:port in the GET request, as some lwp's fail to remove it from the GET line - replace manually coded exception handling with GET_BODY_ASSERT macro PR: Obtained from: Submitted by: Reviewed by: I tend not to clutter the Changes file with test fixes, since they aren't relevant to final users. So the 1.99_09 thread ends here. Will continue the rest in the other thread. __ 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
Re: [mp2] make test fails with 1.99_10-dev sources
Haroon Rafique wrote: Experience with 1.99_10-dev (up to date with CVS till yesterday): = The first batch of tests passes 100%, so the filter/in_bbs_msg.t from 1.99_09 is fixed. However, ModPerl-Registry tests fail with: Failed Test Stat Wstat Total Fail Failed List of Failed --- redirect.t 22 100.00% 1-2 special_blocks.t 122 16.67% 6 10 Both failed due to the missing LWP. I was able to reproduce the exact problem by removing LWP/UserAgent.pm. I have now fixed both in cvs. Please 'cvs up' and test again. Thanks. __ 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
Re: How tell what version of mod_perl is installed?
On Thu, 2003-06-05 at 14:13, Ged Haywood wrote: ... If the question to which you refer is the one in the subject line, then one answer is look in the error log. Apache tells you when it starts. It's generally about the first thing it says. Your error log is defined in your Apache configuration file (probably httpd.conf) in a line that starts ErrorLog I know about that file. However, in my case (~stock Red Hat 8.0 Apache 2.0.40), my error log (/var/log/httpd/error_log) shows: [Thu Jun 05 02:54:44 2003] [notice] Apache/2.0.40 (Red Hat Linux) configured -- resuming normal operations I spent some time scrounging the Apache Web site and can't find any documentation on how to show what DSOs (Dynamic Shared Objects, aka Apache modules) are loaded. Google groups shows some other people having this question. For Apache 1.0, one can inspect the httpd.conf for LoadModule directives. For Apache 2.0 in Red Hat, one can do that but, also, for modules that are packaged as separate RPMs, one must examine /etc/httpd/conf.d/*. Such techniques do not constitute a documented API for finding that information, but are better than nothing. See: http://oceanpark.com/notes/howto_redhat8-apache2-mod_perl.html You can find out what modules are statically linked with your Apache image by doing, for example: [EMAIL PROTECTED] httpd]# httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c apachetcl -l will also do that. But I don't have mod_perl statically linked. It is loaded by my /etc/httpd/conf.d/perl.conf file. You could also take a look at http://perl.apache.org/docs/2.0/user/intro/start_fast.html which has an example of the output in the error log from a server when it's started. But no documentation as to why or how that line is generated nor what it means. If your question isn't the one in the subject line, please accept my apologies - I haven't been following this thread closely. Feel free to ask it again if it hasn't yet been answered. It was in some earlier responses: [EMAIL PROTECTED] root]# perl -Mmod_perl -le 'print mod_perl-VERSION' 1.9905 There's more FM to R if you work with Apache/mod_perl 1.x - if you're going to be doing a lot of work for a commercial application and you don't want to be involved in the mod_perl 2.x development, and you're going to want lots more people around to hold your hand, then that's what I'd recommend. There are good books too. Buy them. Read them. You're an exceptional individual if you can absorb it all the first time through, so read them again. One of the best books I've ever read in my tenure doing software development is the excellent one by Lincoln Stein and Doug MacEachern, Writing Apache Modules with Perl and C. First thing I read back in 1999 when I started using mod_perl. I eagerly await an update that covers Apache 2.0 and mod_perl 2.0. Oh, heck. More advice. 73, Ged. All well founded advice is appreciated. Cheers, Dennis -- Dennis G. Allard telephone: 1.310.399.4740 Ocean Park Software http://oceanpark.com
Re: [mp2] How do I find Documentation on . . .
Stas Bekman wrote: [snip] Fantastic. We really need volunteers to help with the docs (at least manpages). The infrastructure is all there. We use pod and everything gets glued together by DocSet. You can find more info here: http://perl.apache.org/download/docs.html Okay. there are a few bits of the Apache::RequestRec manpage http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html This doc is converted from pod. Okay. You Perl guys with your text processing. What will you think of next ;) So get yourself familiar with the infrastructure, but don't do anything just yet. We have planned a bulked import of documentation bits from the Apache C header files, but it's incomplete. Seeing that it's not getting anywhere and hearing no news from Gerald Richter, I think I'll just go ahead and import whatever we have. And then everybody can chime in and help polish the docs. Sounds like a plan? Aye, Aye. I have some rudimentary docs with the methods listed, and a brief discussion of what they do (the ones I could figure out), but I'll move them to pod and await new content from the import you talk about. -- Jack Nerad
RE: DirectoryIndex doesn't see SetHandler path
I hope that this is the issue. Marc has failed to say that he is using mp2/apache2, so I won't be surprised if this is yet another problem introduced by apache-2.0 (incompatible mod_dir behavior wrt apache-1.3). see my recent bug reports to the httpd-dev list. Yah, yah, sorry, Apache 2.0.46 on W2K, ActiveState build 804 (Perl 5.8), mod_perl/1.99_10-dev. Postcards from the bleeding edge. Wish I'd given more attention to your postings on httpd-dev. I was thinking this might be a bug and it might not...I'm not always sure what is _supposed_ to happen. mma
Trouble with Apache::Request
Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! -- K Old [EMAIL PROTECTED]
RE: Trouble with Apache::Request
Kitch, No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works, as I'm out of things to try. Thanks, Kevin On Fri, 2003-06-06 at 12:39, Kitch, David wrote: Did you do a threaded build of Perl 5.8.0? You might try a non-threaded Perl build. Regards, Kitch [EMAIL PROTECTED] -Original Message- From: K Old [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 11:27 AM To: ModPerl List Subject: Trouble with Apache::Request Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so ' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated!
RE: Trouble with Apache::Request
Hi there, On 6 Jun 2003, K Old wrote: No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works Want to run that by me again?? I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. Is it *exactly* the same error? Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. [snip] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ for module Apache::Request: libapreq.so.1: cannot open shared object file: \ No such file or directory [snip] Is there in fact no such file or directory? I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. 73, Ged.
Re: Trouble with Apache::Request
On Fri, 6 Jun 2003, K Old wrote: Hello everyone, I'm having trouble getting Apache::Request installed on my Mandrake 9.0 system. Let me first say that I'm not using the Apache that came with Mandrake 9.0. I downloaded Apache 1.3.27, mod_perl 1.27 and PHP 4.3.1 sources and compiled and installed them. Everything works fine with Apache, mod_perl and PHP, except when I need to use Apache::Request (trying to use Alzabo browser interface). BTW, the version of Perl is 5.8.0. When trying to build Apache::Request, here's what I get when I do the make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. I've scoured mailing list, Google groups and books and can't find any help. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. [ .. ] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Any help is greatly appreciated! If there's more than one Apache on your system, it may be that libapreq found the wrong one. Does it help any if you specify explicitly the desired Apache at the 'perl Makefile.PL' stage, as discussed in the install file of the distribution? -- best regards, randy kobes
pl extension
Hi I'm running redhat 9 and trying to execute a perl script through a web browser http://host/file.pl and the file displays as text, how do i get my apache to recognize this extension? thanks Paul
[OT] Re: pl extension
Hi! On Thu, Jun 05, 2003 at 11:00:37AM +0200, [EMAIL PROTECTED] wrote: I'm running redhat 9 and trying to execute a perl script through a web browser http://host/file.pl and the file displays as text, how do i get my apache to recognize this extension? This doesn't seems like a mod_perl question to me. Try a general CGI list: http://lists.perl.org/showlist.cgi?name=cgi-list Or read the Apache Docs, especially the section on ScriptAlias: http://httpd.apache.org/docs-2.0/mod/mod_alias.html#scriptalias -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
[mp2] Newbie: How to get CGI params using mp2?
How the heck do you get the parameters from a request? I don't see any methods that look right. I'd expect them to be on Apache::RequestRec, but I can't see anything that is close to matching my idea of what it should be named. Help? -- Jack Nerad
RE: Trouble with Apache::Request
Hi Ged, On Fri, 2003-06-06 at 13:55, Ged Haywood wrote: Hi there, On 6 Jun 2003, K Old wrote: No, I didn't build a threaded Perl, it seems to be the popular thing among any linux distro these days to build it with threads. I'll build a version without threads just to see if it works Want to run that by me again?? Mandrake 9.0 (and several other linux distros) come out of the box with Perl 5.8.0 built with threads. I'm guessing that having Perl compiled with threads might be what's causing the problem in getting Apache::Request installed. I'm having trouble getting Apache::Request installed on my Mandrake 9.0 [snip] make test. I can force the install, but the same error comes up when I try to load Apache::Request as a PerlModule in httpd.conf or when Alzabo calls it. Is it *exactly* the same error? Well, here are the errors I'm getting: When I *force* and install of Apache::Request and a script calls Apache::Request, this is in the error_log: [Fri Jun 6 17:27:31 2003] [error] Can't locate object method new via package Apache::Request at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache/Request.pm line 22. This is from doing a make test when trying to install Apache::Request manually: Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 16) line 3. Still with the forced install of Apache::Request, if I try to call it from httpd.conf via PerlModule Apache::Request, I get this error. Syntax error on line 590 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Apache/Request/Request.so' for module Apache::Request: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229. at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/mod_perl.pm line 14 Compilation failed in require at (eval 4) line 3. Any chance I should build perl without the threads? I've heard that can be the cause of a lot of problems. Just Perl 5.8.0 can cause problems... do you have any others kicking around? I'm thinking of 5.7.2 for example (ducks in case Stas throws something :) which has done me good service. Wouldn't recommend 5.6.anything. I'm starting to agree. Just this afternoon I build Apache::Request without any problems on an RH 7.3 box with Perl 5.6.1 compiled without threads. Anyone else have Apache::Request running under Perl 5.8.0 with threads enabled? [snip] t/httpd -f `pwd`/t/httpd.conf Syntax error on line 31 of /root/.cpan/build/libapreq-1.1/t/httpd.conf: Can't load '/root/.cpan/build/libapreq-1.1/blib/arch/auto/Apache/Request/Request.so' \ for module Apache::Request: libapreq.so.1: cannot open shared object file: \ No such file or directory [snip] Is there in fact no such file or directory? The file Requests.so does exist and it is in the location being referenced. The permissions are 755. I don't like that it's even looking in there... Are you building it all as root? Bad idea generally, although -MCPAN does rather encourage it. Yeah, I hear ya on the CPAN thingI am building it as root, but have tried it as a regular user and get the same errors Any ideas? Thanks for your help, Kevin -- K Old [EMAIL PROTECTED]
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
On Today at 11:32am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB SB Both failed due to the missing LWP. I was able to reproduce the exact SB problem by removing LWP/UserAgent.pm. I have now fixed both in cvs. SB Please 'cvs up' and test again. Thanks. SB after cvs up, make test skipped a bunch of tests in both the first batch and the 2nd batch (since libwww-perl was not installed). 100% successful. After that, I installed: libwww-perl-5.69 CGI.pm-2.93 HTML-Parser-3.28 URI-1.23 to satisfy all dependencies for installing libwww-perl The tests, that were skipped last time around, ran successfully this time. 100%. Now onto investigating my originally reported problem as to why the older, system-wide installation is interfering with the make test. Any suggestions on how to get started on that? Thanks, -- Haroon Rafique [EMAIL PROTECTED]
Re: [mp2] make test fails with 1.99_10-dev sources on redhat
Haroon Rafique wrote: On Today at 11:32am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB SB Both failed due to the missing LWP. I was able to reproduce the exact SB problem by removing LWP/UserAgent.pm. I have now fixed both in cvs. SB Please 'cvs up' and test again. Thanks. SB after cvs up, make test skipped a bunch of tests in both the first batch and the 2nd batch (since libwww-perl was not installed). 100% successful. After that, I installed: libwww-perl-5.69 CGI.pm-2.93 HTML-Parser-3.28 URI-1.23 to satisfy all dependencies for installing libwww-perl The tests, that were skipped last time around, ran successfully this time. 100%. Fantastic, thanks! Now onto investigating my originally reported problem as to why the older, system-wide installation is interfering with the make test. Any suggestions on how to get started on that? I think the issue is very simple: @INC had system libraries dirs before the freshly build ones, so dumping @INC contents prior to libs loading should aid the debug. But please use the latest cvs, since I've messed with @INC a bit recently. In parallel, we are planning to verify .so objects that they were created by the same mod_perl.so to avoid completely this kind of problems. Well it won't prevent the pickup of wrong libraries, it'll just scream aloud when this will happen. So your debug is still very important. __ 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
Re: DirectoryIndex doesn't see SetHandler path
Marc M. Adkins wrote: I hope that this is the issue. Marc has failed to say that he is using mp2/apache2, so I won't be surprised if this is yet another problem introduced by apache-2.0 (incompatible mod_dir behavior wrt apache-1.3). see my recent bug reports to the httpd-dev list. Yah, yah, sorry, Apache 2.0.46 on W2K, ActiveState build 804 (Perl 5.8), mod_perl/1.99_10-dev. Postcards from the bleeding edge. Wish I'd given more attention to your postings on httpd-dev. I was thinking this might be a bug and it might not...I'm not always sure what is _supposed_ to happen. You don't have to keep up with all those bloody^H^H^H^Heeding lists. The issue with Apache 2.0 is that it has totally changed the way it handles existing directories which also happen to be assigned to be handled by handlers. One thing I didn't try is replacing Location containers with Directory . I haven't really delved into the specific issue you have asked about, so I might be talking about a totally irrelevant to your problem thing, that's why I haven't responded in first place, but just wanted to tell that 2.0 behavior might be different. __ 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
Re: Trouble with Apache::Request
[ CC'ing the apreq-dev list. In the future please post apreq build problems questions to the apreq-dev list: http://httpd.apache.org/apreq/ ] K Old, please try the httpd-apreq cvs version: I just did: % cd httpd-apreq % perl-5.8.0-ithread Makefile.PL -httpd /home/httpd/httpd_perl/bin/httpd make test ... All tests successful. This version will be soon released on CPAN, it wasn't released yet due to some polishing of Apache::Test that is now used by Apache::Request for its test suite. Here is how to get the cvs version: % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login CVS password: anonymous % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co httpd-apreq % cd httpd-apreq % cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co \ -d Apache-Test httpd-test/perl-framework/Apache-Test notice that in the example above, you need to adjust a path to your httpd and of course the path to perl, perl-5.8.0-ithread in my case is a symlink to perl-5.8.0 built with threads. If your problem still persists please post the output of your 'perl -V' that you have used to build Apache::Request __ 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
Apache modules and mod_perl threads in same process?
For Apache 2.0.46 / mod_perl 1.99.10-dev: If I have an Apache module configured in httpd.conf, will the module code be executing in the same process as the mod_perl code? If there are multiple Apache processes (on W2K I always see 2) will the module code exist in all processes? mma
Re: Apache modules and mod_perl threads in same process?
Marc M. Adkins wrote: For Apache 2.0.46 / mod_perl 1.99.10-dev: If I have an Apache module configured in httpd.conf, will the module code be executing in the same process as the mod_perl code? If there are multiple Apache processes (on W2K I always see 2) will the module code exist in all processes? I'm assuming that you are talking about threaded mpms (winnt in your case?) Then the answer is yes. Whenever the perchild mpm will be completed, it'll be possible to do grouping. However I'm not sure how applicable that would be to winFU platforms. __ 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