Re: AP2.2.7 + MP2.0.3 on Win32
After some investigation, I realise that it's modperl on Win32 is still more stable on 2.2.4 (ApacheLounge). Some layman findings: 1. Apache2::Reload can cause the startup to crash easily. eg. when you load HTML::Template 2. Fault report on Events is like this: Faulting application httpd.exe, version 2.2.7.0, faulting module msvcrt.dll, version 7.0.3790.3959, fault address 0x00037e23. My interpretation is that it's to do with incompatibilities with the compiler used by ApacheLounge. 3. I tried MP2 on ASF's binary of 2.2.7, with similar results esp. on Apache2::Reload. I've swung back to 2.2.4 and things are much happier now. Foo JH wrote: Hi all, Just want to slap a quick note that I've tried the following combo on Win32 platform (Windows 2003 Server x86): Apache 2.2.7 from ApacheLounge (apachelounge.com) modperl 2.0.3 from theoryx5 (ppd) libapreq 2.6.2 from theoryx5 (ppd) Perl 5.8.8 (ActivePerl build 822) The only thing I'm interested (the rest I take for granted) is that it survives a restart from the ApacheMonitor app. Had painful issues with past versions, so this is always my priority. I know Linuxians take it for granted...
[mp2] [question] $ENV{PATH} changes not taking effect?
I have searched through all the web docs and Usenet, but not found
anything that suggests anything special has to be done in mod_perl
scripts that need to set $ENV{PATH}
My specific example is that I need to add /usr/local/bin to PATH, but
I''ve been unable to find a way to do this, looks like mod_perl
scripts execute the line that changes $ENV{PATH}, but when a qx()
back-tick command is executed, that command is executed under the
value of the original path. One lone posting on Usenet wondered
whether PerlSetEnv in Apache Config is the only way to fix this, but that
seems like a too big a hammer.
In case it helps, here's a simple test on Fedora FC7 system (more
version info at end):
#!/usr/bin/perl -Tw
print "Content-type: text/plain\n\n";
my $command = "basename";
foreach ( "/bin:", "/invalid/dir:" ) {
$ENV{PATH} = $_;
print "-- Testing command '$command', path $ENV{PATH}\n";
my $string = `$command testing` || '';
print "failed to execute '$command', \$? is $?/" . ($? >> 8) . " : $!\n"
if ($? != 0);
print "output \$string is: $string\n";
}
exit(0);
When run from the command line, I get the correct output:
Content-type: text/plain
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
[Wed Jan 16 17:13:39 2008] script.pl: Can't exec "basename": No such
file or directory at /home/cgi/script.pl line 12.
failed to execute 'basename', $? is -1/16777215 : No such file or directory
output $string is:
---
But when I run this under Apache and mod_perl, I get this output -
/bin is still in the PATH even after removal:
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
output $string is: testing
---
/perl-status output snippet:
Embedded Perl version v5.8.8 for Apache/2.2.6
Under the "perl-script" handler, the environment is:
MOD_PERL = mod_perl/2.0.3
MOD_PERL_API_VERSION = 2
PATH = /sbin:/usr/sbin:/bin:/usr/bin
Any help appreciated!
[Please ignore one duplicate email if it shows up - sent before subscribed]
Re: [mp2] [question] $ENV{PATH} changes not taking effect?
What happens if you try running it with the modperl handler instead of
the perl-script handler?
B Wooster wrote:
I have searched through all the web docs and Usenet, but not found
anything that suggests anything special has to be done in mod_perl
scripts that need to set $ENV{PATH}
My specific example is that I need to add /usr/local/bin to PATH, but
I''ve been unable to find a way to do this, looks like mod_perl
scripts execute the line that changes $ENV{PATH}, but when a qx()
back-tick command is executed, that command is executed under the
value of the original path. One lone posting on Usenet wondered
whether PerlSetEnv in Apache Config is the only way to fix this, but that
seems like a too big a hammer.
In case it helps, here's a simple test on Fedora FC7 system (more
version info at end):
#!/usr/bin/perl -Tw
print "Content-type: text/plain\n\n";
my $command = "basename";
foreach ( "/bin:", "/invalid/dir:" ) {
$ENV{PATH} = $_;
print "-- Testing command '$command', path $ENV{PATH}\n";
my $string = `$command testing` || '';
print "failed to execute '$command', \$? is $?/" . ($? >> 8) . " : $!\n"
if ($? != 0);
print "output \$string is: $string\n";
}
exit(0);
When run from the command line, I get the correct output:
Content-type: text/plain
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
[Wed Jan 16 17:13:39 2008] script.pl: Can't exec "basename": No such
file or directory at /home/cgi/script.pl line 12.
failed to execute 'basename', $? is -1/16777215 : No such file or directory
output $string is:
---
But when I run this under Apache and mod_perl, I get this output -
/bin is still in the PATH even after removal:
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
output $string is: testing
---
/perl-status output snippet:
Embedded Perl version v5.8.8 for Apache/2.2.6
Under the "perl-script" handler, the environment is:
MOD_PERL = mod_perl/2.0.3
MOD_PERL_API_VERSION = 2
PATH = /sbin:/usr/sbin:/bin:/usr/bin
Any help appreciated!
[Please ignore one duplicate email if it shows up - sent before subscribed]
--
Jim Brandt
Administrative Computing Services
University at Buffalo
Re: [mp2] [question] $ENV{PATH} changes not taking effect?
Under modperl, get zero bytes output, HTTP response code is 200, though.
Apache error_log shows:
[Thu Jan 17 12:47:15 2008] -e: Can't exec "basename": No such file or
directory at /var/www/perl/script.pl line 12.
So, under modperl, changes to $ENV{PATH} are not accepted (like
perl-script), but the default value for that is probably empty (or
does not contain /bin).
I also tried adding PerlSetEnv in this case, but still same output -
no output, and same error as above, for this Apache config:
SetHandler modperl
PerlSetEnv PATH /bin/:
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
wrote:
> What happens if you try running it with the modperl handler instead of
> the perl-script handler?
Re: [mp2] [question] $ENV{PATH} changes not taking effect?
There's a thread from December that would seem to be related. From that thread:
-- Forwarded message --
From: Michael Schout <[EMAIL PROTECTED]>
Date: Dec 28, 2007 9:12 PM
Subject: Re: mod_perl, ENV{'TZ'}, and localtime
To: Kirk Noda <[EMAIL PROTECTED]>
Cc: modperl@perl.apache.org
Kirk Noda wrote:
> The thread seemed to die off. Still, is there a way to use $ENV{TZ} to
> modify the behavior of localtime?
The reason this does not work under modperl version 2.0 is because under
handler "perl-script", %ENV is untied from the C environment. The
localtime() function is implemented in C, and as a result, it will never
see the changes you made to $ENV{TZ} from mod_perl.
The way I got around this was to use Env::C, and override
CORE::localtime() with something like:
package MyLocaltime;
use Env::C;
sub import {
my $class = shift;
$class->export('CORE::GLOBAL', 'localtime');
}
sub localtime {
my $time = shift;
$time = time unless defined $time;
my $orig_tz = Env::C::getenv('TZ');
Env::C::setenv('TZ', $ENV{TZ}, 1);
my @ret = CORE::localtime($time);
Env::C::setenv('TZ', $orig_tz, 1);
return @ret;
}
The real problem is that this is only safe under a prefork MPM because
it is not thread safe. There really ought to be an option (IMO) where
you can make the untie of %ENV under perl-script to be optional. Maybe
something like PerlOptions +NoUntieEnv or something so that if you are
running under a prefork MPM, you do not need to resort to tactics like
the above.
Regards,
Michael Schout
Re: AP2.2.7 + MP2.0.3 on Win32
thanks, good note. On Jan 14, 2008 5:12 PM, Foo JH <[EMAIL PROTECTED]> wrote: > Hi all, > > Just want to slap a quick note that I've tried the following combo on > Win32 platform (Windows 2003 Server x86): > Apache 2.2.7 from ApacheLounge (apachelounge.com) > modperl 2.0.3 from theoryx5 (ppd) > libapreq 2.6.2 from theoryx5 (ppd) > Perl 5.8.8 (ActivePerl build 822) > > The only thing I'm interested (the rest I take for granted) is that it > survives a restart from the ApacheMonitor app. Had painful issues with > past versions, so this is always my priority. I know Linuxians take it > for granted... > > >
bug Mac os X
Hi, I am attaching the bug report while installing mod_perl in Mac OS X Leopard. Can you please let me know the options I have to sort this. regards aroul. bugreport Description: Binary data
[mp2] [question] How to change $ENV{PATH} for a specific script?
I have searched through all the web docs and Usenet, but not found
anything that suggests anything special has to be done in mod_perl
scripts that need to set $ENV{PATH}
My specific example is that I need to add /usr/local/bin to PATH, but
I''ve been unable to find a way to do this, looks like mod_perl
scripts execute the line that changes $ENV{PATH}, but when a qx()
back-tick command is executed, that command is executed under the
value of the original path.
In case it helps, here's a simple test on Fedora FC7 system (more
version info at end):
#!/usr/bin/perl -Tw
print "Content-type: text/plain\n\n";
my $command = "basename";
foreach ( "/bin:", "/invalid/dir:" ) {
$ENV{PATH} = $_;
print "-- Testing command '$command', path $ENV{PATH}\n";
my $string = `$command testing` || '';
print "failed to execute '$command', \$? is $?/" . ($? >> 8) . " : $!\n"
if ($? != 0);
print "output \$string is: $string\n";
}
exit(0);
When run from the command line, I get the correct output:
Content-type: text/plain
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
[Wed Jan 16 17:13:39 2008] script.pl: Can't exec "basename": No such
file or directory at /home/cgi/script.pl line 12.
failed to execute 'basename', $? is -1/16777215 : No such file or directory
output $string is:
---
But when I run this under Apache and mod_perl, I get this output -
/bin is still in the PATH even after removal:
-- Testing command 'basename', path /bin:
output $string is: testing
-- Testing command 'basename', path /invalid/dir:
output $string is: testing
---
/perl-status output snippet:
Embedded Perl version v5.8.8 for Apache/2.2.6
Under the "perl-script" handler, the environment is:
MOD_PERL = mod_perl/2.0.3
MOD_PERL_API_VERSION = 2
PATH = /sbin:/usr/sbin:/bin:/usr/bin
Any help appreciated!
Re: Re: Re: Re: Process exists - Segmentation fault
Hi,
I was getting some bizarre seg faults with embperl a month or two ago.
The site used to work fine, then it started segfaulting all over the
place after I did a new linux install. I started erasing huge blocks
of code until I found the code responsible: for some reason, having a
BEGIN {} block in my base.html, with a few use's and such in it, was
causing seg faults. I moved that code into startup.pl and it stopped
segfaulting.
I have no idea if this applies to you, Abhishek, but I just wanted to
share.
Greetings,
Allen
On Tue, Jan 15, 2008 at 01:14:57AM +, abhishek jain wrote:
> Hi Gerald,
> Sorry for a late reply ,
> no make test did not worked correctly, it did tested the modperl part and
> gave error like an error on line 21.
> I will try to give the exact error later,
> Thanks,
> Abhishek jain
>
>
> On 1/9/08, Gerald Richter - ECOS GmbH <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Maybe we should go one step back:
> >
> > Does "make test" works correctly for you?
> >
> > Does it also test the mod_perl part?
> >
> > Gerald
> >
> >
> > > -Original Message-
> > > From: abhishek jain [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, January 07, 2008 2:59 AM
> > > To: Gerald Richter
> > > Cc: modperl@perl.apache.org
> > > Subject: Re: Re: Re: Process exists - Segmentation fault
> > >
> > > Hi Its me again,
> > > But still the things are not working right.
> > > I tried to recompile Embperl and put PerlModule Embperl after
> > > LoadModule embperl_module ..
> > >
> > > Now i do not remember it was before or now but after i
> > > uncomment the 'PerlModule Embperl' line and things stop
> > > working i do not receieve $r=shift; variable i mean $r = undef here.
> > > Is it due to something i did during installation of embperl.
> > > Also If i uncomment the line 'MaxRequestsPerChild 1' and
> > > comment 'PerlModule Embperl ' then i recveive this line in
> > > error log [Sun Jan 06 18:44:11 2008] [notice] child pid 30280
> > > exit signal Segmentation fault (11)
> > >
> > > (May be error and page refreshes itself i mean the code
> > > produces output.)
> > >
> > > and page appears , sometimes the same error appears twice and
> > > page does not appears.
> > >
> > > I am not sure have this error been encountered by someone
> > > else but things are not working right for me . Also if
> > > someone wants i can mail the Embperl logs to someone
> > > individually, i do not want to make the logs public.
> > > Pl help. I am working on the site http://delhi.pm.org/ it is
> > > the delhi perl mongers site and people in this group have
> > > limited knowledge of embperl but this will push up the
> > > embperl in Delhi .
> > > --
> > > Thanks
> > > Abhishek jain
> > >
> > >
> > > On 1/4/08, Gerald Richter - ECOS GmbH <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > Not sure if it makes any difference, but the lines
> > >
> > > LoadModule embperl_module
> > >
> > > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Em
> > > bperl/Embp
> > > erl.so
> > > PerlModule Apache::DBI
> > > PerlModule Embperl
> > >
> > > Should be outside of the VirtualHost block (they are
> > > global anyway)
> > >
> > > The other thing that you should make sure, is that
> > > mod_perl is compiled
> > > with the same Perl that Embperl is and both are using
> > > modules from the
> > > path /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
> > >
> > > If there is any version mismatch, things cannot run correctly.
> > >
> > > Gerald
> > >
> > >
> > > > -Original Message-
> > > > From: abhishek jain [mailto: [EMAIL PROTECTED]
> > > > Sent: Thursday, January 03, 2008 8:20 PM
> > > > To: Gerald Richter
> > > > Cc: modperl@perl.apache.org
> > > > Subject: Re: Re: Process exists - Segmentation fault
> > > >
> > > > Hi,
> > > > Adding PerlModule Embperl did not solved the problem , infact
> > > > it aggreviated it. With this the page is not didsplaye at all.
> > > > My apache configuration is:
> > > >
> > > > :80>
> > > > SuexecUserGroup "#" "#"
> > > > ServerName x
> > > > ServerAlias www.x
> > > > DocumentRoot
> > > > ErrorLog /logs/error_log
> > > > CustomLog /logs/access_log combined
> > > > LoadModule embperl_module
> > > > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Em
> > > bperl/Embperl.so
> > > > PerlModule Apache::DBI
> > > > PerlModule Embperl
> > > > >
> > > > Options Indexes IncludesNOEXEC FollowSymLinks
> > > > allow from all
> > > > AllowOverride All
> > > >
> > > > $">
> > > > SetHandler perl-script
> > > > PerlHandler Embperl::Object
> > > > Options ExecCGI
> > > >
> >
Re: [mp2] [question] $ENV{PATH} changes not taking effect?
Bart Schaefer wrote: There's a thread from December that would seem to be related. From that thread: -- Forwarded message -- From: Michael Schout <[EMAIL PROTECTED]> Date: Dec 28, 2007 9:12 PM The real problem is that this is only safe under a prefork MPM because it is not thread safe. There really ought to be an option (IMO) where you can make the untie of %ENV under perl-script to be optional. Maybe something like PerlOptions +NoUntieEnv or something so that if you are running under a prefork MPM, you do not need to resort to tactics like the above. If invoked as a section at startup, you are mislead. The fork and threads creation hasn't happened at that phase.
compiling problems with mod_perl 2.0.3 and Apache 2.2.6
I am having problems a static mod_perl with Apache 2.2.6 and Perl 5.10.0. I followed the instructions for a static build, but when I type make I get the following errors (only a few same error lines are included): httpd-2.2.6/srclib/apr/include/apr.h:273: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'apr_off_t' httpd-2.2.6/srclib/apr-util/include/apr_buckets.h:242: error: expected specifier-qualifier-list before 'apr_off_t' httpd-2.2.6/srclib/apr/include/apr_strings.h:315: error: expected ')' before '*' token mod_perl.c:1058: error: 'request_rec' has no member named 'handler' make[1]: *** [mod_perl.o] Error 1 Any idea on what's going on? Thanks _ Overpaid or Underpaid? Check our comprehensive Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fcontent%2Emycareer%2Ecom%2Eau%2Fsalary%2Dcentre%3Fs%5Fcid%3D595810&_t=766724125&_r=Hotmail_Email_Tagline_MyCareer_Oct07&_m=EXT
question on startup.pl overriding perl search path
I use "PerlConfigRequire /var/www/html/mypath/startup.pl" in httpd.conf to recompile all the CGIs. Inside startup.pl, I added the line: use lib qw(. mylib); To me amazement, after all the CGI is precompiled, they start to look into the "." and "mylib" path for loading Perl Modules without even having the line [use lib qw(. mylib);] incorporated in each individual cgi script. Can someone explain to me why this is the case? Is the mod_perl startup.pl script simply becomes the parent apache process for all the preloaded CGIs? If I remove mod_perl, can I use the PerlSetEnv -I/var/www/html/mypath -I/var/www/html/mypath/lib to achieve the same result. This will make a profound effect on my CGI directory because whatever I installed will no longer affect the system perl module search path. In effect, this will make my application self contained and making trouble shooting make easier. - C Chan
Re: compiling problems with mod_perl 2.0.3 and Apache 2.2.6
Am Freitag, den 18.01.2008, 15:47 +1030 schrieb James Breat: > I am having problems a static mod_perl with Apache 2.2.6 and > Perl 5.10.0. Essentially, the answer you need is: Don't use mod_perl2 and Perl 5.10.0 together yet. As far as I know, the mod_perl developers are working on resolving the issues (caused by internal changes in Perl 5.10) right now. So we both have to wait for mod_perl 2.0.4... heiko
