Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi!
On Thu, Sep 11, 2003 at 10:24:20PM -0500, Randy Kobes wrote:
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32 - I've also put up a ppm package
Oh, great! Thanks Randy! I'll put this into the next release, which should
happen in a few days...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Thu, 11 Sep 2003, Geoffrey Young wrote: The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? Anyway, Apache::Dispatch is now up and running for me. Thanks, Randy! - Steve
Errors in my scripts cause apache getting strange...
Hi all,
I use Apache 1.3.26, mod_perl 1
I use Apache directive
ErrorDocument 500 /error500.html
So, if any errors occure, my web-site inform it in nice form (showing page
/error500.html).
But suddenly i change something in my scripts and now, when error happens,
Apache do not give me /error500.html page, but instead of it apache gets
output like this:
IkH{9`z4'7!?INnIE~G!h?rxC
O|!
and so on
My browser tries to save or open it (it means ContentType is not text/html)
It happens whith errors like this:
[Fri Sep 12 17:16:16 2003] [error] Can't call method commit on an
undefined value at /usr/local/apache-new/htdocs/lib/perl/Model/profile.pl
line 94.
it seems like usual error...
What does it mean?
Where is the reason? I want apche to show me /error500.html again on errors!
Thanks,
Anton Permyakov.
Apache::AuthCookie causing strange-Use of uninitialized value.
I use Apache::AuthCookie 3.04, which seems to be the latest version, under Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26. When I use PerlFixupHandler Apache::AuthCookie-recognize_user, Apache writes Use of uninitialized value. in errorlog for each request and subrequest. I have tried editing AuthCookie.pm, checking everything with defined(), even substituting recognize_user with a stub function. Still it is there. I am not sure it comes from perl, because perl use to say at line X too. But from what else? This has been up before, but no one answered it then: http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: Apache::AuthCookie causing strange Use of uninitialized value.
Thanks for your response! You have to subclass Apache::AuthCookie. This should be something like: PerlFixupHandler Your::Sublass-recognize_user Well, I do. I just pasted the wrong text (from the 2002 mail). The actual configuration snippet is: Location / AuthType TAS::Cookie AuthName TAS PerlFixupHandler TAS::Cookie-recognize_user /Location Another observation: It does only appear when no cookie is received. When users are logged in, everything is fine. And, yes, I checked recognize_user and put in a defined() around the cookie check. No result. Even a bad cookie (manually deleting the session) makes it quiet. /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Have you benchmarked some simple things on the boxes? So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) 73, Ged.
Re: AIX perfomance
On 9/12/03 at 2:07 PM, [EMAIL PROTECTED] (Rafael Garcia-Suarez) wrote: I've a mod_perl application we've developed on Linux and that we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX -- the httpd configuration being similar. And that's mod_perl 1.28. So I'm asking for the common wisdom about performance issues on AIX. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? (which I haven't succeeded to build on AIX 4 by now BTW -- but I'm working on it.) I've built many mod_perl applications on linux and moved them to AIX 4.3.3 with no detriment at all. What do you mean by strangely slow? BIll
Re: AIX perfomance
Ged Haywood wrote: Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Well, it's difficult to compare very different hardware, but basically the AIX boxen have SCSI discs, more memory, etc. and they're a lot more expensive ;-) Have you benchmarked some simple things on the boxes? Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Moreover if I survey CPU/memory usage on Linux and AIX (resp. with top and vmstat / w) I see that the application doesn't swap memory and that the load averages remains 0.10. So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) Thanks, I'll dig deeper.
Re: AIX perfomance
Hi there,
On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote:
Benchmarking simple CPU-intensive perl scripts shows that they
tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
GCC defaults to `-maix32'
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
73,
Ged.
mp2 with perl-5.8.1 on Windows
Hi, Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows? I've got it building, but I can't start the Apache server at all. (It's fine without the mod_perl bits in the httpd.conf file.) See this thread on p5p for what I'm getting: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html Cheers, - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Steve Hay wrote: Randy Kobes wrote: [ .. ] Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. -- best regards, randy
Re: AIX perfomance
On 9/12/03 at 2:54 PM, [EMAIL PROTECTED] (Ged Haywood) wrote:
Benchmarking simple CPU-intensive perl scripts shows that they
tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
GCC defaults to `-maix32'
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
I think it's pretty useless to speculate as to causes until he clarifies what
strangely slow means and what AIX and linux hardware he's comparing. I've got
a lot of experience with mod_perl on both linux and AIX and can state
categorically that there are no typical conditions which would cause AIX run
strangely slowly compared to linux on comparable hardware.
Bill
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, William McCabe wrote: I've got a lot of experience with mod_perl on both linux and AIX and can state categorically that there are no typical conditions which would cause AIX run strangely slowly compared to linux on comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. Roughly what hardware setups do you generally work with, and what differences are notable between Linux and AIX when running mod_perl servers? (If that's not too long a piece of string to measure:). Are there situations where you'd prefer one or the other, if so why? 73, Ged.
Re: AIX perfomance
On Fri, 2003-09-12 at 09:35, Rafael Garcia-Suarez wrote: Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Are these mod_perl scripts or just Perl? If you benchmark some simple Perl scripts that don't run under mod_perl and they show the same trend, then you can eliminate mod_perl as a possible source of the problem. You should also verify that your versions of Perl, apache, and mod_perl are exactly the same on both systems. - Perrin
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Randy Kobes wrote:
[ .. ]
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32
Your patch does the trick for me, except that I had to
rebuild mod_perl too.
The problem is that my installed mod_perl setup (Apache in
C:\apache, Perl in C:\perl5) didn't contain the
mod_perl.lib required. The MODPERL_LIB entry in
Apache::MyConfig said
C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is,
of course, where it was when I was building mod_perl.
I believe that mod_perl 2 now installs the mod_perl.lib
somewhere to solve that kind of problem. Is there an
option in the mod_perl 1 build process to thave that
library installed, or could that be added to the next
release?
That's a good suggestion - you're right that mod_perl 2
installs the mod_perl.lib under the Apache2/ tree, and it
would make sense for mod_perl 1 to do the same, with
Apache::MyConfig adjusted to reflect that. I'll look into
putting together something to do that.
Does it? According to Apache::Build, it should be installed under the apache
tree's lib:
sub modperl_libs_MSWin32 {
my $self = shift;
# mod_perl.lib will be installed into MP_AP_PREFIX/lib
# for use by 3rd party xs modules
$self-{cwd}/src/modules/perl/$self-{MP_LIBNAME}.lib;
}
__
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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... -- best regards, randy
Forking w/ mod_perl 2
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. __ 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: Forking w/ mod_perl 2
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 + threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
signature.asc
Description: This is a digitally signed message part
RE: Forking w/ mod_perl 2
Hi Richard,
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of
code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 +
threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
Thanks for you reply. The report code is in another perl program that I'm
trying to execute. The code I included below was from the v1 docs:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
Here is the code I ended up with:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This seems to work and no zombies are floating around. But I've not been
able to restart Apache while the forked program is running yet to see if
it's killed.
More comments or ideas welcome.
Thanks,
Cameron
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15
minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain
those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
WE: Apache::AuthCookie causing strange-Use of uninitialized value.
It is a warning Perl gives on strict, if variables have 0 values or are
NULL.
The example below will trigger that warning:
###
#!/usr/sbin/perl -w
use strict;
Xyz (fist_value, second_value); # Here we call sub xyz with 2 arguments
Sub xyz {
my ($x,$y,$z)@_;
print $x;
print $y;
print $z; # This will trigger the warning, because $z has no value.
}
To arrest the warning, I may use something like this:
Print $z if $z;
###
-Ursprüngliche Nachricht-
Von: Per Eric Rosén [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. September 2003 13:46
An: [EMAIL PROTECTED]
Betreff: Apache::AuthCookie causing strange-Use of uninitialized
value.
I use Apache::AuthCookie 3.04, which seems to be the latest version,
under
Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2
mod_perl/1.26.
When I use PerlFixupHandler Apache::AuthCookie-recognize_user, Apache
writes Use of uninitialized value. in errorlog for each request and
subrequest. I have tried editing AuthCookie.pm, checking everything with
defined(), even substituting recognize_user with a stub function.
Still it is there. I am not sure it comes from perl, because perl use to
say at line X too. But from what else?
This has been up before, but no one answered it then:
http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html
/Per Eric
--
^): Per Eric Rosén http://rosnix.nu/~per/
/ [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
mod_perl v2 Forking
Hi all...
Sorry about the previous message getting screwed up... Not sure what
happened...
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
Does anyone have ideas as to how to solve this?
Thanks,
Cameron
Re: mod_perl v2 Forking
I've been following this just at a high level, so if I'm posting a method
that you've already tried and dismissed please forgive me.
You can try forking followed by separating from the parent session. I
think that will help keep your program from getting killed when apache is
restarted or stopped.
use POSIX;
# FORK
$pid = fork;
if (not defined $pid) {
# unable to fork
} elsif ($pid) {
# parent to exit, child continue
exit 0;
}
# Separate from parent
$status = 0;
POSIX::setsid() or $status = Couldn't start new session: $!;
if ($status) {
# unable to separate from parent session
} else {
# searated from parent
$status = 0;
}
On Fri, 12 Sep 2003, Cameron B. Prince wrote:
Hi all...
Sorry about the previous message getting screwed up... Not sure what
happened...
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
Does anyone have ideas as to how to solve this?
Thanks,
Cameron
Apache::Session permissions problem
I found a pretty useful article at
http://www.linuxjournal.com/article.php?sid=4143 on how to use
Apache::Session with Mason. I followed the article, more or less, and
ended up with this bit of code in my handler.pl to tie() my $session
variable to an Apache::Session class:
eval {
tie %HTML::Mason::Commands::session, 'Apache::Session::DBI',
($cookies{$session_cookie_name} ?
$cookies{$session_cookie_name}-value() : undef),
{
DataSource = $dbsource,
UserName = $dbuser,
Password = $dbpass
};
};
All the database variables are correct; I use them elsewhere with no
problem. The problem is that the session seems to be intermittent--
some pages seem to recognize it, others don't. This smelled a lot like
a problem where the session was getting set in one Apache instance and
not others, so I wondered if the session was getting stored in the
database correctly; after the previous eval, all I ever get in $@ is:
Permission denied at
/Library/Perl/Apache/Session/SysVSemaphoreLocker.pm line 46.
Which seems to indicate it isn't. I STFW, and found several people who
seem to have had the same problem I have, but the solutions proffered
involve ipcs and ipcrm, which don't exist on my Mac OS X 10.2.6 system.
Suggestions are more than welcome; I'm not quite sure how
Session::SysVSempaphoreLocker got involved in the first place, since I
don't explicitly reference it.
Mightily confused,
-=Eric
