[mp2] PerlInitHandler and PATH_INFO weirdness
Hi List, I am trying to get a rather large-ish web app to run with apache 2 / mod_perl 1.99. I have installed the latest RPMs for Fedora from FreshRPMs. PerlModule Apache2 PerlModule Apache::compat PerlOptions +GlobalRequest PerlOptions +SetupEnv I have a very strange behavior with PerlInitHandlers. When there is no PerlInitHandler, the ENV variable PATH_INFO is around as usual. However, when there is a PerlInitHandler, then the PATH_INFO vanishes and is replaced by SCRIPT_NAME! Any ideas of what might be going on? Cheers, Jean-Michel. -- 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
"Require"
Hi I am using mod_perl 1.29 and perl 5.8.0 on apache_1.3.29 running on RedHat 8.0. CGI scripts have some "require" and some of require are called by PerlRun but some are not... So this output following error message below.. PerlRun: `Undefined subroutine &Apache::ROOT::Scripts::_30311::up_2ecgi::mimeencode called at /usr/local/www/data/Scripts//update.cgi line 476. How does this kind of problem likely happen? Is any bad script in the one called by "require"? Please advise me... hara -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
Jean-Michel Hiver wrote: > Hi List, > > I am trying to get a rather large-ish web app to run with apache 2 / > mod_perl 1.99. I have installed the latest RPMs for Fedora from FreshRPMs. > > PerlModule Apache2 > PerlModule Apache::compat > PerlOptions +GlobalRequest > PerlOptions +SetupEnv > > I have a very strange behavior with PerlInitHandlers. > > When there is no PerlInitHandler, the ENV variable PATH_INFO is around > as usual. > > However, when there is a PerlInitHandler, then the PATH_INFO vanishes > and is replaced by SCRIPT_NAME! > > Any ideas of what might be going on? yes. I would consider it a bug, but mod_perl (through the current release) populated %ENV when the first Perl*Handler runs, which may have been before or after translation (which is where path_info becomes known). if you specifically move that PerlInitHandler to a PerlHeaderParserHandler I'd suspect at PATH_INFO would magically appear. this behavior has been changed in CVS, so in 1.99_13 everything ought to work as expected. However, in 1.99_13 %ENV is only set up right before the PerlResponseHandler, so CGI variables like PATH_INFO and REMOTE_USER will not be present in Perl*Handlers at all - you'll need to use the API to get to them. HTH --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
I would consider it a bug, but mod_perl (through the current release) populated %ENV when the first Perl*Handler runs, which may have been before or after translation (which is where path_info becomes known). if you specifically move that PerlInitHandler to a PerlHeaderParserHandler I'd suspect at PATH_INFO would magically appear. That would explain :) Another thing: In order to make my application to run, for the moment I use Apache::compat as follows: PerlModule Apache2 PerlModule Apache::compat PerlOptions +GlobalRequest PerlOptions +SetupEnv Shouldn't PerlOptions +GlobalRequest +SetupEnv be set by default when using Apache::compat? It is, after all, the default behavior when using mp1. Also, shouldn't Apache::compat 'use' Apache2 to make the 'PerlModule Apache2' unnecessary? this behavior has been changed in CVS, so in 1.99_13 everything ought to work as expected. However, in 1.99_13 %ENV is only set up right before the PerlResponseHandler, so CGI variables like PATH_INFO and REMOTE_USER will not be present in Perl*Handlers at all - you'll need to use the API to get to them. This sounds very sensible. After all Perl*Handler are supposed to use the mod_perl API where ModPerl::Registry scripts aren't. Although it would be nice to have the option to populate %ENV twice: once before the first Perl*Handler and once before the response phase. Thanks, Jean-Michel. -- 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: "Require"
On Thu, 2004-03-04 at 08:56, [EMAIL PROTECTED] wrote: > PerlRun: `Undefined subroutine > &Apache::ROOT::Scripts::_30311::up_2ecgi::mimeencode called at > /usr/local/www/data/Scripts//update.cgi line 476. > > How does this kind of problem likely happen? Is any bad script in the one > called by "require"? This should explain it: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
Jean-Michel Hiver wrote: > >> I would consider it a bug, but mod_perl (through the current release) >> populated %ENV when the first Perl*Handler runs, which may have been >> before >> or after translation (which is where path_info becomes known). if you >> specifically move that PerlInitHandler to a PerlHeaderParserHandler I'd >> suspect at PATH_INFO would magically appear. >> > That would explain :) :) > > Another thing: In order to make my application to run, for the moment I > use Apache::compat as follows: > > PerlModule Apache2 > PerlModule Apache::compat > PerlOptions +GlobalRequest > PerlOptions +SetupEnv > > Shouldn't PerlOptions +GlobalRequest +SetupEnv be set by default when > using Apache::compat? hmm... probably. I'm not sure if there is an API for setting those, though. > > It is, after all, the default behavior when using mp1. > > Also, shouldn't Apache::compat 'use' Apache2 to make the 'PerlModule > Apache2' unnecessary? I don't think so. it's probably better to let the admin determine where the installation ought to point to, rather than compat (or any other module) figuring it out for him - if there is an old Apache2/ install sitting around and a newer one in Apache/ things won't be right. > >> this behavior has been changed in CVS, so in 1.99_13 everything ought to >> work as expected. However, in 1.99_13 %ENV is only set up right >> before the >> PerlResponseHandler, so CGI variables like PATH_INFO and REMOTE_USER will >> not be present in Perl*Handlers at all - you'll need to use the API to >> get >> to them. >> > This sounds very sensible. After all Perl*Handler are supposed to use > the mod_perl API where ModPerl::Registry scripts aren't. Although it > would be nice to have the option to populate %ENV twice: once before the > first Perl*Handler and once before the response phase. if you call subprocess_env() in a void context with no arguments: $r->subprocess_env(); %ENV will be set up. it will be set up _again_ before content generation to make sure that new subprocess_env entries make in into %ENV as well. so, we gotcha covered. now, anyway :) --Geoff -- 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: Cannot set content-type different from text/html
> ALL OTHER URLS (/) must go to the mode_perl handler are you 100% sure about that. it's probably really not what you want, but only you know your application. but ok, you can do that by setting up your mod_perl stuff HTH --Geoff -- 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::Session maintainership
On Thu, 26 Feb 2004 12:29:20 -0800 "Jeffrey W. Baker" <[EMAIL PROTECTED]> wrote: > On Wed, 2004-02-25 at 16:42, Dave Rolsky wrote: > > On Wed, 25 Feb 2004, Casey West wrote: > > > > > of work for the maintainer in working through the mailing list archives > > > > Or maintainer_s_. Why not set up an SF project for this? Then you and > > Enrico can both do work on it. There's no reason a Perl module needs one > > and only one maintainer. > > SourceForget is truly terrible and I would not burden the users with the > horror of having to use it. > > Casey's ideas are excellent and show certain forthought and taste. I'm > happy with Enrico's ideas also. So here's what I'd like to do: > > Either or both of you, or anyone on this list, should send your patches > for inclusion in the next release (1.7). After any features are added > and tests written for them, we'll make a new release. If it goes well, > I'll fiddle with CPAN to hand over maintainership to Casey, who could > then add uploaders as required. Hi Jeff, it's fine to me. Also, a CVS-like environment would be much appreciated, as suggested by Dave, where we could have commit access by - Enrico -- 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: funny action of crypt
At 16:55 2004-03-03 -0800, you wrote:
>I have a problem when my apache_1.3.29 w/ mod_perl 1.29 runs PerlRun
>and some CGI scripts with password encryption.
>$password = crypt($password, &mkSalt($name.$password.$value) );
I'm no expert, but here goes... There are 2 ways of implementing crypt(3):
using DES or MD5 based algorithms. If the value of $password is undef or an
empty string, chances are your glibc only supports the MD5 flavor of crypt,
because your mkSalt() always generates a salt that only DES can use. MD5
salt values begin with '$1$'. See
http://unixhelp.ed.ac.uk/CGI/man-cgi?crypt+3.
# 1st value is DES crypt, 2nd is MD5
print crypt $password, mkSalt($name . $password . $value);
print crypt $password, '$1$';
Perhaps you need to rewrite mkSalt() so it supports MD5 salts as well, if
that's what your system's crypt() expects (?).
>sub mkSalt {
> local($t, $sum, @salt ) = @_;
> @salt = split(//,
>'./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz');
> if ($t) {
>$sum = unpack("%12C*", $t);
> } else { # ハンドルが空の場合
>return 'No';
> }
> $salt[$sum % 64] . $salt[int($sum/64) % 64];
>}
--
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: funny action of crypt
>Perhaps you need to rewrite mkSalt() so it supports MD5 salts as well, if
>that's what your system's crypt() expects (?).
Talking of which, I've managed to find a subroutine I wrote that does
exactly this...
#
# generate_salt()
# generates a random "salt" for use with crypt(3), which Perl's crypt()
# is based on.
#
# Notes
# The DES based algorithm uses a salt of 2 characters drawn from the range
# [a-zA-Z0-9./]. MD5 uses a variable length salt: '$1$' (the signature
# that tells crypt(3) the caller wants MD5 encryption rather than DES)
# followed by 0-8 characters of the same range as the DES salt, followed
# optionally by '$'.
#
# /\A[a-zA-Z0-9.\/]{2}\z/ // regex for DES salt
# /\A\$1\$[a-zA-Z0-9.\/]{0,8}\$?\z/ // regex for MD5 salt
#
# Returns
# a "salt" string appropriate for crypt(3) - may be DES or MD5 salt
#
sub generate_salt {
my $algo = choose_crypt_algo($PREFERRED_CRYPT_ALGO);
my @salt_chars = ('a'..'z', 'A'..'Z', 0..9, '.', '/');
my ($salt, $salt_length);
srand;### set random number seed for CORE::rand
if ( $algo & $DES_CRYPT ) { ### chosen crypt algorithm is DES
$salt= '';
$salt_length = 2;
}
else {### chosen crypt algorithm is MD5
$salt= '$1$'; # MD5 salt prefix
$salt_length = int rand 9; # random integer from 0 to 8 inclusive
}
while ($salt_length--) { ### randomly generate the salt
my $idx = int rand @salt_chars;
$salt .= $salt_chars[$idx];
}
return $salt;
}
hth,
Mark
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
Geoffrey Young wrote: Another thing: In order to make my application to run, for the moment I use Apache::compat as follows: PerlModule Apache2 PerlModule Apache::compat PerlOptions +GlobalRequest PerlOptions +SetupEnv Shouldn't PerlOptions +GlobalRequest +SetupEnv be set by default when using Apache::compat? hmm... probably. I'm not sure if there is an API for setting those, though. We have the way to do it: Apache->server->add_config(['PerlOptions +GlobalRequest +SetupEnv']); But normally, those options are set in httpd.conf's specific containers and not always globally for the whole server. I'm not sure it's a good idea to enforce these settings for the whole server. What do you think? It is, after all, the default behavior when using mp1. Also, shouldn't Apache::compat 'use' Apache2 to make the 'PerlModule Apache2' unnecessary? I don't think so. it's probably better to let the admin determine where the installation ought to point to, rather than compat (or any other module) figuring it out for him - if there is an old Apache2/ install sitting around and a newer one in Apache/ things won't be right. I agree with Geoff. We could certainly add it, but it takes control away from people. You can't undo things after Apache2 is loaded. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
> We have the way to do it: > > Apache->server->add_config(['PerlOptions +GlobalRequest +SetupEnv']); > > But normally, those options are set in httpd.conf's specific containers > and not always globally for the whole server. I'm not sure it's a good > idea to enforce these settings for the whole server. What do you think? I'm not sure. I'm trying to decide what is expected when someone uses Apache::compat. I think it ought to be API compatibility, not config compatibility. so, +SetupEnv doesn't qualify, since it's on by default for perl-script under mp1 and mp2. +GlobalRequest is a likely candidate, though, since Apache->request ought to work under the compat layer. but maybe we could inject +GlobalRequest on demand rather than on module load - kind of like the override foo for methods that collide with core mp2 ones. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
Geoffrey Young wrote: We have the way to do it: Apache->server->add_config(['PerlOptions +GlobalRequest +SetupEnv']); But normally, those options are set in httpd.conf's specific containers and not always globally for the whole server. I'm not sure it's a good idea to enforce these settings for the whole server. What do you think? I'm not sure. I'm trying to decide what is expected when someone uses Apache::compat. I think it ought to be API compatibility, not config compatibility. so, +SetupEnv doesn't qualify, since it's on by default for perl-script under mp1 and mp2. +GlobalRequest is a likely candidate, though, since Apache->request ought to work under the compat layer. but maybe we could inject +GlobalRequest on demand rather than on module load - kind of like the override foo for methods that collide with core mp2 ones. You have the API to do that override already. Add as the first line in your script: $r = shift; Apache->request($r); and if we provide this override API, it might be too late if you use: Apache->server->add_config(['PerlOptions +GlobalRequest']); or too early if you use: $r = shift; Apache->request($r); depending on where the user have called that overriding API from. Besides, as you have pointed out Apache::compat does *not* provide you a complete back compatibility by just loading it. Several back-compat functions need to be enabled explicitly. For example: http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_finfo_ http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_notes_ and a few more. So there is always a chance that you need to do more than just loading Apache::compat. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
> You have the API to do that override already. Add as the first line in > your script: > > $r = shift; Apache->request($r); that's not the same. in mp1 Apache->request is used for pulling $r out of thin air. isn't +GlobalRequest for that exact circumstance, allowing you to get at $r when none is otherwise available to you? --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] PerlInitHandler and PATH_INFO weirdness
Geoffrey Young wrote:
You have the API to do that override already. Add as the first line in
your script:
$r = shift; Apache->request($r);
that's not the same. in mp1 Apache->request is used for pulling $r out of
thin air. isn't +GlobalRequest for that exact circumstance, allowing you to
get at $r when none is otherwise available to you?
Once you run the above at the very beginning of your script, it'll pull out $r
out from thin air from that point on. that's exactly what +GlobalRequest does.
For example you can write:
PerlModule Apache::compat
PerlPostReadRequestHandler 'sub { Apache->request(shift); Apache::DECLINED }'
and it'll be an exact equivalent of:
PerlModule Apache::compat
PerlOptions +GlobalRequest
assuming that none resets PerlPostReadRequestHandler handlers.
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] $timeout & Re: "server failed to start!"
Dear mod_perl community,
Randy Kobes <[EMAIL PROTECTED]> wrote at Wed, 3 Mar
2004 19:54:47 -0600
... snip ...
>> >waiting 120 seconds for server to start: giving up after 121 secs
>> >!!! server failed to start!
... snip ...
>
>Does it help if you set the APACHE_TEST_STARTUP_TIMEOUT
>environment variable to, say, 200?
Alas no, it does not, as shown below:
>/usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_12/t -f /
>usr/local/src/mod_perl-1.99_12/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
>using Apache/2.0.48 (prefork MPM)
>
>waiting 300 seconds for server to start:
>. snip
>waiting 300 seconds for server to start: giving up after 301 secs
>!!! server failed to start!
>
>canebas.org [753]% ps ax | grep httpd
>12016 pts/9S 0:00 /usr/local/apache2/bin/httpd -d /usr/local/
>src/mod_perl-1.99_12/t -f /usr/local/src/mod_perl-1.99_12/t/conf/
>httpd.conf -DAPACHE2 -DPERL_USEITHREADS
In addition, version 1.99_12 of mod_perl ignores the value of the
environment APACHE_TEST_STARTUP_TIMEOUT because the test script now
assign's a value to the configuration variable 'startup_timeout', and
that will always override APACHE_TEST_STARTUP_TIMEOUT because as line 526
of Apache-Test/lib/Apache/TestServer.pm reads:
my $timeout = $vars->{startup_timeout} ||
$ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
60;
The value of the configuration setting 'startup_timeout' is automatically
generated at line 21 of lib/ModPerl/TestRun.pm. So the only way right
now to change the value of the $timeout variable above is to edit lib/
ModPerl/TestRun.pm (or eqv.)
Thanks to everyone who contributes to the mod_perl project!
Edouard :-)
--
Edouard Lagache, Sysadmin
canebas.org
[EMAIL PROTECTED]
29 Altamount Drive
Orinda, CA, 94563
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $timeout & Re: "server failed to start!"
> my $timeout = $vars->{startup_timeout} ||
> $ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
> 60;
I swapped the order in CVS. thanks.
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $timeout & Re: "server failed to start!"
Edouard Lagache wrote:
Dear mod_perl community,
Randy Kobes <[EMAIL PROTECTED]> wrote at Wed, 3 Mar
2004 19:54:47 -0600
... snip ...
waiting 120 seconds for server to start: giving up after 121 secs
!!! server failed to start!
... snip ...
Does it help if you set the APACHE_TEST_STARTUP_TIMEOUT
environment variable to, say, 200?
Alas no, it does not, as shown below:
Try:
t/TEST -startup_timeout=600
In addition, version 1.99_12 of mod_perl ignores the value of the
environment APACHE_TEST_STARTUP_TIMEOUT because the test script now
assign's a value to the configuration variable 'startup_timeout', and
that will always override APACHE_TEST_STARTUP_TIMEOUT because as line 526
of Apache-Test/lib/Apache/TestServer.pm reads:
my $timeout = $vars->{startup_timeout} ||
$ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
60;
The value of the configuration setting 'startup_timeout' is automatically
generated at line 21 of lib/ModPerl/TestRun.pm. So the only way right
now to change the value of the $timeout variable above is to edit lib/
ModPerl/TestRun.pm (or eqv.)
Thanks for pointing that out. That will be fixed in 1.99_13.
Thanks to everyone who contributes to the mod_perl project!
Thanks for the 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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $timeout & Re: "server failed to start!"
Geoffrey Young wrote:
my $timeout = $vars->{startup_timeout} ||
$ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
60;
I swapped the order in CVS. thanks.
No, Geoff, the order was correct. Command line options override env vars.
The correct patch seems to be:
Index: lib/ModPerl/TestRun.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/TestRun.pm,v
retrieving revision 1.19
diff -u -r1.19 TestRun.pm
--- lib/ModPerl/TestRun.pm 4 Mar 2004 06:01:06 - 1.19
+++ lib/ModPerl/TestRun.pm 4 Mar 2004 22:27:08 -
@@ -32,6 +32,7 @@
# default timeout in secs (threaded mpms are extremely slow to
# startup, due to a slow perl_clone operation)
$self->{conf_opts}->{startup_timeout} ||=
+$ENV{APACHE_TEST_STARTUP_TIMEOUT} ||
Apache::Build->build_config->mpm_is_threaded() ? 300 : 120;
$self->{conf_opts}->{maxclients} ||= MIN_MAXCLIENTS;
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] -startup_timeout broke? (was: "server failed to start!")
Stas Bekman <[EMAIL PROTECTED]> wrote at Thu, 4 Mar 2004 14:24:59 -0800 >Edouard Lagache wrote: ... snip ... >waiting 120 seconds for server to start: giving up after 121 secs >!!! server failed to start! ... snip ... > >Try: > >t/TEST -startup_timeout=600 *Sigh* trying this literally causes: >canebas.org [780]% t/TEST -startup_timeout=600 >!!! unknown opts or test names: -startup_timeout=600 >-help will list options Just in case of command line processing weirdness I tried: >canebas.org [776]% t/TEST -startup_timeout 600 >/usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_12/t -f / >usr/local/src/mod_perl-1.99_12/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS >using Apache/2.0.48 (prefork MPM) > >waiting 120 seconds for server to start: ^^^ >. Sad to report that either way - not the desired outcome (???) My five cent attempt to peer into the mod_perl code in search of the cause went nowhere. Sorry, folks - back to you'all! Peace, Edouard P.S. Just to be sure, I uncompressed a new distribution from the 1.99_12 tarball before running any of the above. -- Edouard Lagache, Sysadmin canebas.org [EMAIL PROTECTED] 29 Altamount Drive Orinda, CA, 94563 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] -startup_timeout broke?
Edouard Lagache wrote: Stas Bekman <[EMAIL PROTECTED]> wrote at Thu, 4 Mar 2004 14:24:59 -0800 Edouard Lagache wrote: ... snip ... waiting 120 seconds for server to start: giving up after 121 secs !!! server failed to start! ... snip ... Try: t/TEST -startup_timeout=600 *Sigh* trying this literally causes: ah, sorry, I should have checked before suggesting that option. It was fixed in the current cvs: modperl-2.0/Changes: make 't/TEST -startup_timeout secs' working (previously user's value was ignored) [Stas] so either just change lib/ModPerl/TestRun.pm to set a higher value, or use the current cvs (which is the preferred way, so you can test the latest fixes). But something is telling me that this is not the real problem. The process starts but probably it doesn't respond. A simple: t/TEST -ping will tell you whether it's really running or just hanging there. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] Server unresponsive (Re: "server failed to start!")
Stas Bekman <[EMAIL PROTECTED]> wrote at Thu, 4 Mar 2004 15:23:04 -0800 >But something is telling me that this is not the real problem. The process >starts but probably it doesn't respond. A simple: > >t/TEST -ping > >will tell you whether it's really running or just hanging there. Indeed your hypothesis is correct: >canebas.org [785]% t/TEST -ping >*** no server is running on localhost:8529 >canebas.org [786]% ps ax | grep httpd >21564 pts/9S 0:00 /usr/local/apache2/bin/httpd -d /usr/local/ >src/mod_perl-1.99_12/t -f /usr/local/src/mod_perl-1.99_12/t/conf/ >httpd.conf -DAPACHE2 -DPERL_USEITHREADS I'll snag a copy of the current CVS to see if that helps. Thank you for everyone's help! Peace, Edouard :-) -- Edouard Lagache, Sysadmin canebas.org [EMAIL PROTECTED] 29 Altamount Drive Orinda, CA, 94563 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] $timeout & Re: "server failed to start!"
On Thu, 4 Mar 2004, Edouard Lagache wrote: > Dear mod_perl community, > > Randy Kobes <[EMAIL PROTECTED]> wrote at Wed, 3 Mar > 2004 19:54:47 -0600 > ... snip ... > > > >Does it help if you set the APACHE_TEST_STARTUP_TIMEOUT > >environment variable to, say, 200? > > Alas no, it does not, as shown below: > > >/usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_12/t -f / > >usr/local/src/mod_perl-1.99_12/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS > >using Apache/2.0.48 (prefork MPM) > > > >waiting 300 seconds for server to start: > >. snip > >waiting 300 seconds for server to start: giving up after 301 secs > >!!! server failed to start! > > Is there anything in the mod_perl t/logs/ error log that's relevant? In particular, is there any suggestions about raising some Apache configuration limits? -- 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
Re: funny action of crypt
Philippe M. Chiasson wrote: On Wed, 2004-03-03 at 18:14 -0800, Stas Bekman wrote: [EMAIL PROTECTED] wrote: Hi I have a problem when my apache_1.3.29 w/ mod_perl 1.29 runs PerlRun and some CGI scripts with password encryption. Script is ... $password = crypt($password, &mkSalt($name.$password.$value) ); [...] mod_perl 2 has a workaround for 5.8.0: /* This was fixed in 5.9.0/5.8.1 (17775), but won't compile after 19122 */ #if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 0 && \ defined(USE_REENTRANT_API) && defined(HAS_CRYPT_R) && defined(__GLIBC__) /* workaround perl5.8.0/glibc bug */ PL_reentrant_buffer->_crypt_struct.current_saltbits = 0; #endif I haven't seen it in the mp1 code. Is this workaround worth considering for backporting in mp1 ? Looks like so. Hara has failed to respond back to the list and emailed me privately. And this did solve his problem after he stuck the above code somewhere in mod_perl.c. And yes, he was running 5.8.0. __ 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 -- 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: funny action of crypt
On Thu, 2004-03-04 at 14:21 -0800, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > On Wed, 2004-03-03 at 18:14 -0800, Stas Bekman wrote: > > > >>[EMAIL PROTECTED] wrote: > >> > >>>Hi > >>> > >>>I have a problem when my apache_1.3.29 w/ mod_perl 1.29 runs PerlRun > >>>and some CGI scripts with password encryption. > >>> > >>>Script is ... > >>> > >>>$password = crypt($password, &mkSalt($name.$password.$value) ); > >>> > >>>[...] > >> > >>mod_perl 2 has a workaround for 5.8.0: > >> > >>/* This was fixed in 5.9.0/5.8.1 (17775), but won't compile after 19122 */ > >>#if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 0 && \ > >> defined(USE_REENTRANT_API) && defined(HAS_CRYPT_R) && defined(__GLIBC__) > >> /* workaround perl5.8.0/glibc bug */ > >> PL_reentrant_buffer->_crypt_struct.current_saltbits = 0; > >>#endif > >> > >>I haven't seen it in the mp1 code. > > > > > > Is this workaround worth considering for backporting in mp1 ? > > Looks like so. Hara has failed to respond back to the list and emailed me > privately. And this did solve his problem after he stuck the above code > somewhere in mod_perl.c. And yes, he was running 5.8.0. Allright, I'll apply this fix to mp1 soon then. > __ > 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 signature.asc Description: This is a digitally signed message part
Re: funny action of crypt
Philippe M. Chiasson wrote: On Thu, 2004-03-04 at 14:21 -0800, Stas Bekman wrote: Philippe M. Chiasson wrote: On Wed, 2004-03-03 at 18:14 -0800, Stas Bekman wrote: [EMAIL PROTECTED] wrote: Hi I have a problem when my apache_1.3.29 w/ mod_perl 1.29 runs PerlRun and some CGI scripts with password encryption. Script is ... $password = crypt($password, &mkSalt($name.$password.$value) ); [...] mod_perl 2 has a workaround for 5.8.0: /* This was fixed in 5.9.0/5.8.1 (17775), but won't compile after 19122 */ #if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 0 && \ defined(USE_REENTRANT_API) && defined(HAS_CRYPT_R) && defined(__GLIBC__) /* workaround perl5.8.0/glibc bug */ PL_reentrant_buffer->_crypt_struct.current_saltbits = 0; #endif I haven't seen it in the mp1 code. Is this workaround worth considering for backporting in mp1 ? Looks like so. Hara has failed to respond back to the list and emailed me privately. And this did solve his problem after he stuck the above code somewhere in mod_perl.c. And yes, he was running 5.8.0. Allright, I'll apply this fix to mp1 soon then. I thought this had to do with threads... writing a test case that you can reproduce the problem with should be helpful. Could probably check the archives to find the discussion about the original report. The issue was with rand always starting from the same init value under threads. But I'm not sure how this affects a single interpreter-process. -- __ 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 -- 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
