RE: PerlModule options?
Hi again Stas Perrin, So, its a no-can-do then. I'll keep putting the use in every module to import the symbols in the proper namespace. Alternatively I guess I could probably use the functions with fully qualfied name Apache::ReadConfig::myFunction(), however this would add extra typing and this is exactly what I was trying to escape from. Thanks everyone for your time and kind answers. Cheers, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 7:08 PM To: Mike P. Mikhailov Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PerlModule options? Mike P. Mikhailov wrote: Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl I think Lian was asking how to import symbols into his scripts/handlers at the server startup. Lian, you *must* put the special line in each and every script you want the symbols to be exported to, because exporting happens inside the script's namespace, which is no main:: under Apache::Registry, but special for each script. You can preload registry scripts using Apache::RegistryLoader, but this doesn't remove the need for an explicit import. __ 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: PerlModule options?
Mike P. Mikhailov wrote: Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl I think Lian was asking how to import symbols into his scripts/handlers at the server startup. Lian, you *must* put the special line in each and every script you want the symbols to be exported to, because exporting happens inside the script's namespace, which is no main:: under Apache::Registry, but special for each script. You can preload registry scripts using Apache::RegistryLoader, but this doesn't remove the need for an explicit import. __ 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: PerlModule options?
On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
RE: PerlModule options?
Hello Mike, Thanks for your answer, this should do it indeed. Super! Somehow I didn't think about perl sections... Thanks again, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Mike P. Mikhailov [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 2:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. cfr Thanks a bunch, cfr Lian Sebe, M.Sc. cfr Freelance Analyst-Programmer cfr www.programEz.net I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 I believe in God, only I spell it Nature.
Re: PerlModule options?
Hello [EMAIL PROTECTED], Tuesday, August 05, 2003, 2:55:52 PM, you wrote: cfr Hi list, cfr One questions for the braves ;-) cfr As I understand, the directive cfr PerlModule Foo::Bar cfr loads the module but doesn't import the symbols since it is equivalent to cfr the use Foo::Bar (). Therefore I should use use Foo::Bar in each program cfr only to make the import. cfr Is there other way to load the module and import the symobols specified in cfr @EXPORT at mod_perl reloading time, without adding a special line in each cfr and every script using them? cfr Perhaps some options passed to PerlModule though adding (...) doesn't help cfr since PerlModule expects a list of modules. cfr Thanks a bunch, cfr Lian Sebe, M.Sc. cfr Freelance Analyst-Programmer cfr www.programEz.net I think this will work perl use Foo::Bar qw ( ... whatever you want to import ... ); /perl -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 I believe in God, only I spell it Nature.
RE: PerlModule options?
On Tue, 2003-08-05 at 15:57, [EMAIL PROTECTED] wrote: Thanks for your answer, this should do it indeed. Super! Somehow I didn't think about perl sections... Perl sections will not work for this. If you do it there, the symbols you want will only get imported into the Apache::ReadConfig namespace. You will not be able to call them in other scripts without importing them there too. - Perrin
Re: PerlModule options?
[EMAIL PROTECTED] wrote: Hi again Stas Perrin, So, its a no-can-do then. I'll keep putting the use in every module to import the symbols in the proper namespace. Alternatively I guess I could probably use the functions with fully qualfied name Apache::ReadConfig::myFunction(), however this would add extra typing and this is exactly what I was trying to escape from. Thanks everyone for your time and kind answers. You can define your export symbols in @EXPORT and they will be all exported by default, on 'use Module;'. See the Exporter manpage for more details. __ 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: PerlModule options?
Hi Perrin, I see your point. However I'm speaking about one simple templating module exporting 2 functions that are used to generate HTML in every other module on the server. So it'll be pollution but bearable ;-) Thank you, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 8:29 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PerlModule options? On Tue, 2003-08-05 at 04:55, [EMAIL PROTECTED] wrote: loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Correct. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? No, that would be Bad. By putting a use Foo in each module that wants to import functions from Foo, you are explicitly saying please pollute my namespace to Foo. That sort of thing shouldn't happen unless you request it. Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. There's no way it could since PerlModule has no way of knowing what namespaces you are going to want polluted. - Perrin
PerlModule options?
Hi list, One questions for the braves ;-) As I understand, the directive PerlModule Foo::Bar loads the module but doesn't import the symbols since it is equivalent to the use Foo::Bar (). Therefore I should use use Foo::Bar in each program only to make the import. Is there other way to load the module and import the symobols specified in @EXPORT at mod_perl reloading time, without adding a special line in each and every script using them? Perhaps some options passed to PerlModule though adding (...) doesn't help since PerlModule expects a list of modules. Thanks a bunch, Lian Sebe, M.Sc. Freelance Analyst-Programmer www.programEz.net
Help - SEGFAULTS on 'PerlModule' after version upgrade
Ugggh: My software works with the 'original server settings', (apache
1.3.24/mod_perl 1.26) see below(1), under linux.
It doesn't work with 'new server settings', (apache 1.3.26 / mod_perl
1.26) see below(2), under freeBSD.
Symptoms:
With the new build, I get seg faults with 'some' of the PerlModules
included through PerlModule in various virtualhosts. Other modules work.
These packages all run with strict and do not include any XS besides what
may hide under the cover with DBI, Date::Calc and Template. I also have a
headache. The packages were happily being included into my old build and
there is nothing unusual about them. An strace displays the last couple
of lines before a segfault as follows:
Server Settings follow this Block===
stat(/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Date/Calc/Calc.bs,
{st_mode=S_IFREG|0444, st_size=0, ...}) = 0
sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0
open(/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Date/Calc/Calc.so,
O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0555, st_size=105794, ...}) = 0
read(7, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 )\0\000...,
4096) = 4096
mmap(0, 102400, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x28316000
mmap(0x2832e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7,
0x17000) = 0x2832e000
close(7)= 0
access(/usr/lib/libperl.so.3, F_OK) = 0
open(/usr/lib/libperl.so.3, O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0444, st_size=615768, ...}) = 0
read(7, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0|O\1\000...,
4096) = 4096
mmap(0, 622592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x2832f000
mmap(0x283bd000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7,
0x8d000) = 0x283bd000
mmap(0x283c6000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x283c6000
close(7)= 0
access(/usr/lib/libm.so.2, F_OK) = 0
access(/usr/lib/libm.so.2, F_OK) = 0
access(/usr/lib/libutil.so.3, F_OK) = 0
sigprocmask(SIG_SETMASK, [], NULL) = 0
sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0
sigprocmask(SIG_SETMASK, [], NULL) = 0
--- SIGSEGV (Segmentation fault) ---
--- SIGSEGV (Segmentation fault) ---
===
Can someone please help?? I can provide a fuller strace if someone
might be able to decipher my problem from this.
Very, very, lost,
Cheers,
Rafiq
SERVER CONFIGS:
(1)'original server settings'
-
Server version: Apache/1.3.24 (Unix)
Modperl: 1.26
Compiled-in modules:
http_core.c
mod_so.c
Server compiled with
-D EAPI
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT=/usr/local/apache
-D SUEXEC_BIN=/usr/local/apache/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/httpd.scoreboard
-D DEFAULT_LOCKFILE=logs/httpd.lock
-D DEFAULT_XFERLOG=logs/access_log
-D DEFAULT_ERRORLOG=logs/error_log
-D TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
-D ACCESS_CONFIG_FILE=conf/access.conf
-D RESOURCE_CONFIG_FILE=conf/srm.conf
(2)'new server settings':
-
Server version: Apache/1.3.26 (Unix)
Mod_Perl: 1.26
Compiled-in modules:
http_core.c
mod_so.c
Server compiled with
-D HAVE_MMAP
-D USE_MMAP_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FLOCK_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D SO_ACCEPTFILTER
-D ACCEPT_FILTER_NAME=httpready
-D HTTPD_ROOT=/usr/local
-D SUEXEC_BIN=/usr/local/sbin/suexec
-D DEFAULT_PIDLOG=/var/run/httpd.pid
-D DEFAULT_SCOREBOARD=/var/run/httpd.scoreboard
-D DEFAULT_LOCKFILE=/var/run/httpd.lock
-D DEFAULT_ERRORLOG=/var/log/httpd-error.log
-D TYPES_CONFIG_FILE=etc/apache/mime.types
-D SERVER_CONFIG_FILE=etc/apache/httpd.conf
-D ACCESS_CONFIG_FILE=etc/apache/access.conf
-D RESOURCE_CONFIG_FILE=etc/apache/srm.conf
Re: Help - SEGFAULTS on 'PerlModule' after version upgrade
Rafiq Ismail (ADMIN) wrote: Ugggh: My software works with the 'original server settings', (apache 1.3.24/mod_perl 1.26) see below(1), under linux. It doesn't work with 'new server settings', (apache 1.3.26 / mod_perl 1.26) see below(2), under freeBSD. Symptoms: With the new build, I get seg faults with 'some' of the PerlModules included through PerlModule in various virtualhosts. Other modules work. These packages all run with strict and do not include any XS besides what may hide under the cover with DBI, Date::Calc and Template. I also have a headache. The packages were happily being included into my old build and there is nothing unusual about them. An strace displays the last couple of lines before a segfault as follows: See, http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems you need to send the gdb backtrace, not the strace's output. FWIW, I've had segfaults on 'use DBI' with mod_perl 2.0/perl 5.8.0, which have gone after I've updated the DBI package. Try to do the same. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Problems with PerlModule
Nikolaus Rath wrote: Hallo! Is it possible that PerlModule doesn't modify %INC? With PerlModule CGI in the Apache configuration, all scripts with use CGI produce warnings like: Subroutine put redefined at /usr/lib/perl5/5.6.1/CGI.pm line 517. Subroutine print redefined at /usr/lib/perl5/5.6.1/CGI.pm line 523. Subroutine cgi_error redefined at /usr/lib/perl5/5.6.1/CGI.pm line 529. Subroutine save_request redefined at /usr/lib/perl5/5.6.1/CGI.pm line [..] in the server log. (use strict and use warnings are active). Without PerlModule, all scripts run without warnings. And even with Perl use CGI; /Perl everything works fine. The CGI module is only an example. I have similar problems with several other modules. When reporting problems you *must* provide the information about your environment and used version as explained here: http://perl.apache.org/release/docs/1.0/guide/help.html#How_to_Report_Problems I believe that this particular problem has been solved in the recent mod_perl versions. -- __ 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: PerlModule hell - questions and comments
Kee Hinckley wrote:
At 4:18 PM -0500 3/22/02, Perrin Harkins wrote:
Modules loaded with PerlModule and PerlRequire are not supposed to be
loaded again the second time. I seem to remember that they are loaded
again when using DSO though, so if you're using DSO you may want to
recompile as static. Also, if you have PerlFreshRestart on that will
cause a reload.
If all you were doing was loading a normal Perl module, the single load
would be fine. The catch is that in this case we are loading a Perl
module which in turn is registering an Apache module. The Apache module
is being *unloaded* prior to the second pass through the config file.
The only way that it will be reloaded is if the Perl module is reloaded
on the second pass as well.
If all you want to do is to be able to load the module only during the
restart use in startup.pl:
if ($Apache::Server::ReStarting) {
require My::Sensitive::Module;
}
--
__
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: PerlModule hell - questions and comments
At 7:04 PM +0800 3/23/02, Stas Bekman wrote:
If all you want to do is to be able to load the module only during
the restart use in startup.pl:
if ($Apache::Server::ReStarting) {
require My::Sensitive::Module;
}
No, the module has to be loaded during both phases, other wise the
configuration file syntax extensions it adds won't be loaded. The
sequence is:
1. Module loads
2. On load, module registers as an Apache module
3. On the second parse of the config file, apache asks module to unload
4. Perl module unregisters itself
5. Module isn't reloaded (because perl modules get loaded only once)
6. Apache module doesn't get reloaded
7. Config file parse fails with syntax errors
You would think that I could just skip step #4, but as far as I can
tell that leaves stale pointers around, at least on some
platforms/configurations. It also doesn't seem proper in general.
The only work-around I have is to add an perl section that calls
the initialization manually. That works, but one would hope that
Perl modules could be treated as first-class Apache modules with
extra magic in the config file.
BTW. I thought that startup.pl was only called once, so your
suggestion would only work inside a perl directive anyway?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
[EMAIL PROTECTED]
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Re: PerlModule hell - questions and comments
Kee Hinckley wrote: 1. *Why* are the apache config files executed twice (completely with loading and unloading all the modules)? This is a core apache thing. Apache does it to verify that a restart is safe. See http://thingy.kcilink.com/modperlguide/config/Apache_Restarts_Twice_On_Start.html I'm not saying I think it's the greatest idea, but that's the reason behind it. Modules loaded with PerlModule and PerlRequire are not supposed to be loaded again the second time. I seem to remember that they are loaded again when using DSO though, so if you're using DSO you may want to recompile as static. Also, if you have PerlFreshRestart on that will cause a reload. A couple of people reported a bug that they were seeing which caused these modules to be loaded twice anyway. That sounds like the issue you saw with Perl sections. I haven't tested this myself, and fixing it would probably require help from Doug. As a workaround, it is possible to do all of your module loading from a startup.pl called from PerlRequire, and avoid that problem. That's what I do. Of course my goal here sounds like exactly the opposite of yours: you actually *want* Embperl to get loaded both times so that your conf directives will work. I haven't run into that problem before because I don't use any modules that add conf directives. Maybe Gerald will have an explanation of what the expected behavior is on his end. It can't be this much trouble for most people or no one would be using Embperl or custom conf directives. - Perrin
Re: PerlModule hell - questions and comments
At 4:18 PM -0500 3/22/02, Perrin Harkins wrote: Modules loaded with PerlModule and PerlRequire are not supposed to be loaded again the second time. I seem to remember that they are loaded again when using DSO though, so if you're using DSO you may want to recompile as static. Also, if you have PerlFreshRestart on that will cause a reload. If all you were doing was loading a normal Perl module, the single load would be fine. The catch is that in this case we are loading a Perl module which in turn is registering an Apache module. The Apache module is being *unloaded* prior to the second pass through the config file. The only way that it will be reloaded is if the Perl module is reloaded on the second pass as well. A couple of people reported a bug that they were seeing which caused these modules to be loaded twice anyway. That sounds like the issue you saw with Perl sections. I haven't tested this myself, and fixing it would probably require help from Doug. As a workaround, it is possible to do all of your module loading from a startup.pl called from PerlRequire, and avoid that problem. That's what I do. That doesn't solve the problem because it won't load twice, and the Apache module won't get reloaded. because I don't use any modules that add conf directives. Maybe Gerald will have an explanation of what the expected behavior is on his end. It can't be this much trouble for most people or no one would be using Embperl or custom conf directives. At Embperl 2.0b6 Gerald switched to a new architecture. The previous version was just a plain Perl module loaded as a handler by mod_perl. This version is also an Apache module. Maybe we need an option for PerlModule that forces a load each time? -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: PerlModule hell - questions and comments
Kee Hinckley wrote: At Embperl 2.0b6 Gerald switched to a new architecture. The previous version was just a plain Perl module loaded as a handler by mod_perl. This version is also an Apache module. Okay, if it's only in the recent betas then it's possible that only a few people have encountered this. Can anyone else who has built a module with custom conf directives comment on this issue? Maybe we need an option for PerlModule that forces a load each time? It seems like something to keep the C and perl sides doing the same thing is what's needed, so that if the C stuff gets unloaded the perl stuff will too. In your case, PerlFreshRestart might help with what you're trying to do since it will clear %INC, but you may still have the problem with needing to call Init. - Perrin
Re: PerlModule hell - questions and comments
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote: Kee Hinckley wrote: At Embperl 2.0b6 Gerald switched to a new architecture. The previous version was just a plain Perl module loaded as a handler by mod_perl. This version is also an Apache module. Okay, if it's only in the recent betas then it's possible that only a few people have encountered this. Can anyone else who has built a module with custom conf directives comment on this issue? I should note that it also appears to be at least partially either an architecture or configuration issue. The original code which worked for Gerald didn't call unload in its cleanup handler. However that did not work on my system (MacOS X), and on at least one other system (Linux). I found that I had to call unload for things to work, and then it wasn't getting it reloaded. So there may be another way to fix the problem. Suggestions are more than welcome. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: PerlModule hell - questions and comments
At 5:11 PM -0500 3/22/02, Perrin Harkins wrote: In your case, PerlFreshRestart might help with what you're trying to do since it will clear %INC, but you may still have the problem with needing to call Init. PerlFreshRestart will reload the module and thus call Init, but PerlFreshRestart is only called when we fork a new process, it is not called between the first and second parsing of the config file at startup. That seems like a bug to me. If reading the config file twice is intended to ensure that subsequent re-reads on HUP will work, then *everything* should be the same, and that means if PerlFreshRestart is set, it ought to happen there as well. Oddly enough though, PerlFreshRestart is not required for this to work after a HUP, even though it would seem to make sense. Looking at my debug output, it appears that -HUP doesn't cause the cleanup handlers to be called, so the module is never unloaded. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
RE: PerlModule not updating %INC
-Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 20, 2001 6:43 PM To: David Pisoni; [EMAIL PROTECTED]; Robert Landrum Subject: Re: PerlModule not updating %INC [snip] It sounds like this is a real bug with PerlModule. This was supposed to be fixed by 1.26, but I guess the fix didn't work or it got broken again. (Doug?) I wonder if this has something to do with the multiple init thing http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2 if the interpreter is really being entirely broken down on each restart (including the initial one that Apache does when it reparses httpd.conf) %INC might be getting mucked up... --Geoff
Re: PerlModule not updating %INC
I wonder if this has something to do with the multiple init thing
http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2
It does. It's exactly the same bug.
if the interpreter is really being entirely broken down on each restart
(including the initial one that Apache does when it reparses httpd.conf)
%INC might be getting mucked up...
It shouldn't. I thought the interpreter didn't actually get broken down on
restart at all unless you have PerlFreshRestart on. However, I see that
Doug said this:
i think that using *Apache::ReadConfig elsewhere will still trigger the
double loading of all Perl{Require,Module}s, but i doubt the people
suffering from the double load problem are using that feature. so i'll
deal with that later.
David, are you using Apache::ReadConfig or anything that uses it?
- Perrin
RE: PerlModule not updating %INC
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 21, 2001 11:01 AM
To: Geoffrey Young; [EMAIL PROTECTED]; David Pisoni
Subject: Re: PerlModule not updating %INC
I wonder if this has something to do with the multiple init thing
http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2
It does. It's exactly the same bug.
if the interpreter is really being entirely broken down on
each restart
(including the initial one that Apache does when it
reparses httpd.conf)
%INC might be getting mucked up...
It shouldn't. I thought the interpreter didn't actually get
broken down on
restart at all unless you have PerlFreshRestart on.
However,
I see that
Doug said this:
i think that using *Apache::ReadConfig elsewhere will still
trigger the
double loading of all Perl{Require,Module}s, but i doubt the people
suffering from the double load problem are using that
feature. so i'll
deal with that later.
yeah, I read that and didn't understand the how patch he offered worked here
at all.
IIRC, I ran a test with only httpd.conf.default with only these additions
PerlModule My::Foo
then
package My::Foo;
warn initializing...;
in lib/perl and I got 'initializing' on each restart. no Apache::ReadConfig
going on here.
I may have time to test this again today, but if someone else could verify,
that would be great.
--Geoff
Re: PerlModule not updating %INC
IIRC, I ran a test with only httpd.conf.default with only these additions PerlModule My::Foo then package My::Foo; warn initializing...; in lib/perl and I got 'initializing' on each restart. no Apache::ReadConfig going on here. And no PerlFreshRestart?
RE: PerlModule not updating %INC
-Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 11:12 AM To: Geoffrey Young; [EMAIL PROTECTED]; David Pisoni Subject: Re: PerlModule not updating %INC IIRC, I ran a test with only httpd.conf.default with only these additions PerlModule My::Foo then package My::Foo; warn initializing...; in lib/perl and I got 'initializing' on each restart. no Apache::ReadConfig going on here. And no PerlFreshRestart? nope - I literally copied the default httpd.conf and added the single PerlModule directive. maybe a ServerName and Port change too, but no other mod_perl stuff. this drove me batty as I was trying to document how module initialization code worked. I did lots of archive digging and convinced myself that the current behavior is broken and that Doug thinks that what we all expect to see is the proper behavior, despite the fact that I created mod_perl builds back to 1.24 and saw the same thing. --Geoff
RE: PerlModule not updating %INC
ok, here was my test... [geoff@mainsheet apache]$ diff -u conf/httpd.conf.default conf/httpd.conf --- conf/httpd.conf.default Wed Nov 21 02:00:16 2001 +++ conf/httpd.conf Wed Nov 21 11:59:35 2001 @@ -38,6 +38,8 @@ # server as /usr/local/apache/logs/foo.log. # +PerlModule My::Foo + ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, @@ -248,7 +250,7 @@ # don't use Group #-1 on these systems! # User nobody -Group #-1 +Group nobody # # ServerAdmin: Your address, where problems with the server should be [geoff@mainsheet apache]$ cat lib/perl/My/Foo.pm package My::Foo; open my $fh, '/tmp/test'; print $fh scalar localtime, \n; 1; [geoff@mainsheet apache]$ cat /tmp/test [geoff@mainsheet apache]$ ./bin/apachectl start ./bin/apachectl start: httpd started [geoff@mainsheet apache]$ cat /tmp/test Wed Nov 21 12:01:06 2001 [geoff@mainsheet apache]$ ./bin/apachectl restart ./bin/apachectl restart: httpd restarted [geoff@mainsheet apache]$ cat /tmp/test Wed Nov 21 12:01:06 2001 Wed Nov 21 12:01:17 2001 that's not what we should be seeing, right? --Geoff [geoff@mainsheet apache]$ HEAD http://mainsheet.laserlink.net:8080 200 OK Connection: close Date: Wed, 21 Nov 2001 17:04:08 GMT Accept-Ranges: bytes Server: Apache/1.3.23-dev (Unix) mod_perl/1.26_01-dev Content-Length: 413 Content-Type: text/html ETag: 6b82a-19d-3bdd9d6c Last-Modified: Mon, 29 Oct 2001 18:18:20 GMT Client-Date: Wed, 21 Nov 2001 17:04:08 GMT Client-Peer: 10.5.6.32:8080
Re: PerlModule not updating %INC
At 11.00 -0500 11/21/2001, Perrin Harkins wrote: SNIP David, are you using Apache::ReadConfig or anything that uses it? - Perrin Nope, not using ReadConfig. And to address another point, the behavior is consistant regardless of whether or not PerlFreshRestart is on. David
Re: PerlModule not updating %INC
Hello, I hate to keep banging this old drum, but since I was able to reproduce this problem (but not solve it), I figured I'd recycle it again. Perrin said earlier that this was fixed in 1.26, but I am indeed using 1.26 and the problem persists. Stas suggested upgrading perl to 5.6.1 -- I did so, recompiled mod_perl, and the problem persists. I didn't try upgrading the perl on my darwin box, but the fact that I get the same result there is telling. Can anyone tell me what the fix was from 1.25 to 1.26? Maybe there's a clue there. Thanks, David I'm still having this problem, and I've discovered that it is also happening on my darwin box. This is enough to lead me to believe the problem is bona fide. To recap: problem occurs on : Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26 Problem : PerlModule does not cause %INC to be updated, but 'use' does Symptoms : Apache::StatINC does not work for said modules. Said modules do not appear in Apache::Status loaded modules page, but do appear in the Inheritance tree. Ideas? Thanks, David Date: Thu, 18 Oct 2001 12:57:27 -0800 To: Stas Bekman [EMAIL PROTECTED] From: David Pisoni [EMAIL PROTECTED] Subject: Re: PerlModule not updating %INC Cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Bcc: X-Attachments: At 1.13 +0800 10/17/2001, Stas Bekman wrote: David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded with PerlModule directives. What should I try next. :-) David Original Message : Hello, We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. We are running these on a RedHat Linux 7.1, kernel v2.4.2 system. We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. I could not find any documentation suggesting that the PerlModule directive would successfully load a module while circumventing %INC, nor do I recall in my previous projects developed using mod_perl having this problem. (Although I've been away awhile -- maybe I forget.) Any guidance? Thanks,
Re: PerlModule not updating %INC
At 2:31 PM -0800 11/20/01, David Pisoni wrote: We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. I just reread your original post... I think I may know what the problem is (maybe). Are you using Location handlers? Location /whatever SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module /Location If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. And did this fix your problem with Apache::StatINC too? Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: PerlModule not updating %INC
At 18.02 -0500 11/20/2001, Robert Landrum wrote: At 2:31 PM -0800 11/20/01, David Pisoni wrote: We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. I just reread your original post... I think I may know what the problem is (maybe). Are you using Location handlers? Location /whatever SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module /Location If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. And did this fix your problem with Apache::StatINC too? Rob Yes. StatINC indeed uses %INC to do its magic. StatINC's success or failure in this situation is merely a symptom though, not the real problem. We could simply set our configuration files as I've described here, but I'm interested in mod_perl working correctly for everyone, hence I continue to beat this drum. :-) I don't assume that the problem is unique to us -- rather I assume that we're the only ones experiencing it who both realize it and are doing something about it. Thanks, David
Re: PerlModule not updating %INC
If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use Location /whatever SetHandler perl-script PerlHandler My::Special::Module /Location and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. I could be wrong... but I think that the answer is that It's not a bug, it's a feature, and that the behavior is actually correct. Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: PerlModule not updating %INC
At 18.32 -0500 11/20/2001, Robert Landrum wrote: If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use Location /whatever SetHandler perl-script PerlHandler My::Special::Module /Location and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. If this is true, it is a change from prior behavior. (And a bit distressing.) I for one would not complain of Apache::StatINC dirtying memory pages -- I'm really only concerned with shared memory on a production server, and I wouldn't run StatINC outside of the development environment. Besides, I'm assuming that if I do my trick of calling 'use' in a Perl block (which DOES update %INC) that the module code pages are still shared. What is more distressing though is that StatINC may not be the only consumer of %INC. (e.g., Apache::Status does not report these modules in Loaded Modules) The real trouble is that it is deviating from Doing the Right Thing by perl. I could be wrong... but I think that the answer is that It's not a bug, it's a feature, and that the behavior is actually correct. For the above reasons, I hope you are wrong. :-) But you may be right! David
RE: PerlRequire/PerlModule and %INC
hi guys... I know this is from a while ago, but I'm still seeing the double init thing with PerlModule and PerlRequire on server restarts. I've tried two different 5.6.1 installs with current CVS. can somebody verify that I'm not seeing things? the test I was using was the default httpd.conf.default with just a single PerlModule statement, trying to boil things down. thanks --Geoff -Original Message- From: Stas Bekman To: Perrin Harkins Cc: mod_perl list Sent: 8/6/01 11:03 PM Subject: Re: PerlRequire/PerlModule and %INC On Mon, 6 Aug 2001, Perrin Harkins wrote: There have been some messages on the Mason list about people experiencing startup.pl being loaded twice, even without PerlFreshRestart on. I know the server restarts during startup, but PerlRequire and PerlModule are both supposed to obey the laws of %INC, right? I seem to remember some discussion about this before, but I can't remember what the outcome was and I can't find it in the archive. The discussion is here: http://forum.swarthmore.edu/epigone/modperl/lelswyskix The patch is here: http://forum.swarthmore.edu/epigone/modperl/lelswyskix/Pine.LNX.4.21.010 [EMAIL PROTECTED] it's already fixed in 1.26. I've tested again just in case, it works properly now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlModule not updating %INC
I'm still having this problem, and I've discovered that it is also happening on my darwin box. This is enough to lead me to believe the problem is bona fide. To recap: problem occurs on : Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26 Problem : PerlModule does not cause %INC to be updated, but 'use' does Symptoms : Apache::StatINC does not work for said modules. Said modules do not appear in Apache::Status loaded modules page, but do appear in the Inheritance tree. Ideas? Thanks, David Date: Thu, 18 Oct 2001 12:57:27 -0800 To: Stas Bekman [EMAIL PROTECTED] From: David Pisoni [EMAIL PROTECTED] Subject: Re: PerlModule not updating %INC Cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Bcc: X-Attachments: At 1.13 +0800 10/17/2001, Stas Bekman wrote: David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded with PerlModule directives. What should I try next. :-) David
Re: PerlModule not updating %INC
At 1.13 +0800 10/17/2001, Stas Bekman wrote: David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded with PerlModule directives. What should I try next. :-) David
Re: PerlModule not updating %INC
David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlModule not updating %INC
At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? David
PerlModule not updating %INC
Hello, We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. We are running these on a RedHat Linux 7.1, kernel v2.4.2 system. We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. I could not find any documentation suggesting that the PerlModule directive would successfully load a module while circumventing %INC, nor do I recall in my previous projects developed using mod_perl having this problem. (Although I've been away awhile -- maybe I forget.) Any guidance? Thanks, -- David Pisoni One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man. -Elbert Hubbard, author, editor, printer (1856-1915)
Re: PerlModule not updating %INC
We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin
Re: PerlModule not updating %INC
At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. Enjoy, David
Re: PerlModule not updating %INC
At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin
Re: PerlModule not updating %INC
At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David
Re: PerlModule Error
Ken Williams wrote: [EMAIL PROTECTED] (Rasoul Hajikhani) wrote: use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same Here it is: Undefined subroutine My::Perl::Control::WebAccess::handler called. Looks like you need to check the capitalization on 'MY'. I chnaged the name to MIS_APPS::RHS::Control::WebAccess.pm but still get the same error. By the way, using the MY:: namespace isn't the greatest idea in the first place, because the MY:: namespace is used by MakeMaker during modules' installation process. I'm sure it's not causing a problem here, but it can at least create confusion in the mind. You are right, this did not solve the problem. -r ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: PerlModule Error
Stas Bekman wrote: On Thu, 23 Aug 2001, Rasoul Hajikhani wrote: ___cliff rayman___ wrote: and what do the error logs say? Rasoul Hajikhani wrote: I know this question will sound primitive to most of you, however, I have this nagging error which won't go away. In my httpsd.conf, I have declared PerlModule MY::Perl::Control::WebAccess which I know is where it is supposed to be. My @INC does not include the path to that directory, however, in my startup.pl I have that directory as my use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same result: apache won't start. I mean what's up? I have another module sitting next to my MY::Perl::Control::WebAccess and in my startup.pl I have: use MY::Perl::Control::Cookie_Check; and all is fine and dandy... apache runs without a hitch. I tried perl5lib (all capital) in my .cshrc, again nothing. Now I come to you learned people in the hope of salvation... Any ideas people? -r -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Here it is: Undefined subroutine My::Perl::Control::WebAccess::handler called. That's not the error that we want to see. The error you've listed can happen when you actually generate some request. But that's after Apache You are right. Apache does not even start. has started. PerlModule on the other hand merely loads the file similar to use. As you say use() doesn't work for you too. Are you sure you can perform: % perl -c MY/Perl/Control/WebAccess.pm Yes, I get WebAccess.pm syntax OK result. remove the error_log file before you start a new test and see what happens. If you still fail to find the problem. Take your code and shrink it to smallest possible size, while it still imposes a problem for you and together with the configuration section for this module send it to the list. Remember, we want a simple test that we can easily understand and reproduce the problem with. Thanks. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
PerlModule Error
I know this question will sound primitive to most of you, however, I have this nagging error which won't go away. In my httpsd.conf, I have declared PerlModule MY::Perl::Control::WebAccess which I know is where it is supposed to be. My @INC does not include the path to that directory, however, in my startup.pl I have that directory as my use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same result: apache won't start. I mean what's up? I have another module sitting next to my MY::Perl::Control::WebAccess and in my startup.pl I have: use MY::Perl::Control::Cookie_Check; and all is fine and dandy... apache runs without a hitch. I tried perl5lib (all capital) in my .cshrc, again nothing. Now I come to you learned people in the hope of salvation... Any ideas people? -r
Re: PerlModule Error
and what do the error logs say? Rasoul Hajikhani wrote: I know this question will sound primitive to most of you, however, I have this nagging error which won't go away. In my httpsd.conf, I have declared PerlModule MY::Perl::Control::WebAccess which I know is where it is supposed to be. My @INC does not include the path to that directory, however, in my startup.pl I have that directory as my use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same result: apache won't start. I mean what's up? I have another module sitting next to my MY::Perl::Control::WebAccess and in my startup.pl I have: use MY::Perl::Control::Cookie_Check; and all is fine and dandy... apache runs without a hitch. I tried perl5lib (all capital) in my .cshrc, again nothing. Now I come to you learned people in the hope of salvation... Any ideas people? -r -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: PerlModule Error
___cliff rayman___ wrote: and what do the error logs say? Rasoul Hajikhani wrote: I know this question will sound primitive to most of you, however, I have this nagging error which won't go away. In my httpsd.conf, I have declared PerlModule MY::Perl::Control::WebAccess which I know is where it is supposed to be. My @INC does not include the path to that directory, however, in my startup.pl I have that directory as my use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same result: apache won't start. I mean what's up? I have another module sitting next to my MY::Perl::Control::WebAccess and in my startup.pl I have: use MY::Perl::Control::Cookie_Check; and all is fine and dandy... apache runs without a hitch. I tried perl5lib (all capital) in my .cshrc, again nothing. Now I come to you learned people in the hope of salvation... Any ideas people? -r -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Here it is: Undefined subroutine My::Perl::Control::WebAccess::handler called. -r
Re: PerlModule Error
On Thu, 23 Aug 2001, Rasoul Hajikhani wrote: ___cliff rayman___ wrote: and what do the error logs say? Rasoul Hajikhani wrote: I know this question will sound primitive to most of you, however, I have this nagging error which won't go away. In my httpsd.conf, I have declared PerlModule MY::Perl::Control::WebAccess which I know is where it is supposed to be. My @INC does not include the path to that directory, however, in my startup.pl I have that directory as my use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same result: apache won't start. I mean what's up? I have another module sitting next to my MY::Perl::Control::WebAccess and in my startup.pl I have: use MY::Perl::Control::Cookie_Check; and all is fine and dandy... apache runs without a hitch. I tried perl5lib (all capital) in my .cshrc, again nothing. Now I come to you learned people in the hope of salvation... Any ideas people? -r -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Here it is: Undefined subroutine My::Perl::Control::WebAccess::handler called. That's not the error that we want to see. The error you've listed can happen when you actually generate some request. But that's after Apache has started. PerlModule on the other hand merely loads the file similar to use. As you say use() doesn't work for you too. Are you sure you can perform: % perl -c MY/Perl/Control/WebAccess.pm remove the error_log file before you start a new test and see what happens. If you still fail to find the problem. Take your code and shrink it to smallest possible size, while it still imposes a problem for you and together with the configuration section for this module send it to the list. Remember, we want a simple test that we can easily understand and reproduce the problem with. Thanks. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: PerlModule Error
[EMAIL PROTECTED] (Rasoul Hajikhani) wrote: use lib qw(...);. I have tried declaring: use MY::Perl::Control::WebAccess; in my startup.pl, with the same Here it is: Undefined subroutine My::Perl::Control::WebAccess::handler called. Looks like you need to check the capitalization on 'MY'. By the way, using the MY:: namespace isn't the greatest idea in the first place, because the MY:: namespace is used by MakeMaker during modules' installation process. I'm sure it's not causing a problem here, but it can at least create confusion in the mind. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
PerlModule
My apache server does not start up when I add PerlModule B::TerseSize to the httpsd.conf file. Or any PerlModule flag. Any one can tell me why? I am trying to determine a leakage in my script... thanks -r
Re: PerlModule
My apache server does not start up when I add PerlModule B::TerseSize to the httpsd.conf file. Or any PerlModule flag. Any one can tell me why? I am trying to determine a leakage in my script... Do you have B::TerseSize installed on your system? It's not a standard module. Check your error_log for messages. - Perrin
Modules `use`d by PerlModule vanishing after startup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have recently been working on a framework for moving our applications to mod_perl but I've run into a very odd problem. I load our program's main Apache handler, with: PerlModule IQGroup::IQCoordinator And then set it up as a PerlHandler for a virtual host. But when I attempt to load the program, it fails and throws this into the error log: [Thu Aug 9 14:29:05 2001] [error] Can't locate object method GetCurrentRequest via package IQGroup::Core::ApacheRequest (perhaps you forgot to load IQGroup::Core::ApacheRequest?) at /usr/lib/perl5/5.6.1/IQGroup/IQCoordinator.pm line 60. Except it IS being loaded, it's the first module `use`d by our PerlHandler. A trace on the Apache process even shows the module being read at startup. When I insert Apache::Status and take a look at the symbol table, it shows the IQGroup::Core::ApacheRequest namespace, but with no symbols in it! Even more odd, the modules that it in turn uses DO show up, all symbols intact. Now, if I load the handler in the startup file: use IQGroup::IQCoordinator; then everything loads properly, although I get a slew of subroutine blah redefined messages in the error log when it hits the PerlModule directive. This doesn't seem like intended behavior (nothing I read suggests it's supposed to work like this)...so what's eating my module's symbol table? - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBO3Lr3gOGqGs0PadnEQLHTACgrvUHoQSRdUDYntXkzmnCOapDy5MAn2Ex HIvS8i793nzDBqowJ/EMf7T9 =0PSY -END PGP SIGNATURE-
PerlRequire/PerlModule and %INC
There have been some messages on the Mason list about people experiencing startup.pl being loaded twice, even without PerlFreshRestart on. I know the server restarts during startup, but PerlRequire and PerlModule are both supposed to obey the laws of %INC, right? I seem to remember some discussion about this before, but I can't remember what the outcome was and I can't find it in the archive. - Perrin
Re: PerlRequire/PerlModule and %INC
On Mon, 6 Aug 2001, Perrin Harkins wrote: There have been some messages on the Mason list about people experiencing startup.pl being loaded twice, even without PerlFreshRestart on. I know the server restarts during startup, but PerlRequire and PerlModule are both supposed to obey the laws of %INC, right? I seem to remember some discussion about this before, but I can't remember what the outcome was and I can't find it in the archive. The discussion is here: http://forum.swarthmore.edu/epigone/modperl/lelswyskix The patch is here: [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/lelswyskix/[EMAIL PROTECTED] it's already fixed in 1.26. I've tested again just in case, it works properly now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
PerlModule vs use in a Perl section
I was using Apache::Status to learn a bit about what is loaded by my server, and I am wondering about a detail... If I put this: Perl use Apache::Foo; /Perl Or this: PerlModule Apache::Foo I would expect the two to behave the same, but they don't! The "use" in the Perl section does as I was expecting (the module and everything it loaded was right there), but while the PerlModule seemed to change something (Apache::Util was loaded, which I use in my Apache::Foo module), Apache::Foo itself wasn't on the list of loaded modules! Using a "+" when installing the PerlHandler (like this: "PerlHandler +Apache::Foo") did load the module as expected. Now, why aren't modules loaded with PerlModule not showing up in the loaded modules list of Apache::Status? Thanks! -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
[bug] PerlModule reloads modules twice on start
I've noticed an inconcistency between PerlModule and use() (and
PerlRequire and require()).
When Apache starts, it immediately restarts itself to see whether it can
sustain the reload. So when you have
PerlModule Apache::Registry
you will see:
Subroutine handler redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 27.
Subroutine compile redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 174.
Subroutine parse_cmdline redefined at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Registry.pm line 190.
but if you have:
use Apache::Registry;
in startup.pl/Perl sections, Perl won't reload the files, since they are
already in %INC.
So it looks to me that Perl{Module|Require} directives should check %INC,
before execute the load.
This behavior is seen under Perl 5.6.x (apache 1.3.17 /mod_perl-1.25). I
think that I didn't see it under 5.005_03.
And Matt, as I've told you before that I saw:
Subroutine import redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 15.
Subroutine package_to_module redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 22.
Subroutine register_module redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 29.
Subroutine handler redefined at
/usr/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 48.
It has nothing to do with Apache::Reload.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
'PerlModule Apache' creates a error when include in httpd.conf-trying to fix 'Apache.pm failed to load' problem
Problem: I configure apache and mod_perl. One day it runs fine. The next day I stop and start the server and get a 'Apache.pm failed' problem. I looked at the web site and found I needed to add ' PerlModule Apache' to my httpd.conf file. I get the error message listed below. I looked at the web site again and made sure that I was performing the 'make' and 'make install' steps for mod_perl. I get the same syntax error. I looked at the 'PerlSetEnv' command and didn't think it was the solution. Does anyone have any ideas? The error message and other details are listed below. Peggy Malone System Details: Apache version: 1.3.14 mod_perl version: 1.24_01 OS version: SunOS Generic_106541-09 sun4u sparc SUNW,Ultra-1 perl version: 5.005_03 built for sun4-solaris perl location:/usr/local/bin/perl complier version: gcc 2.95.2 -Error message # /usr/local/apache/bin/apachectl start [Thu Jan 11 16:08:15 2001] [error] Can't locate Apache.pm in @INC (@INC contains: /usr/local//lib/perl5/5.00503/sun4-solaris /usr/local//lib/perl5/5.00503 /usr/local//lib/perl5/site_perl/5.005/sun4-solaris /usr/local//lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at (eval 1) line 3. Syntax error on line 745 of /usr/local/apache/conf/httpd.conf: Can't locate Apache.pm in @INC (@INC contains: /usr/local//lib/perl5/5.00503/sun4-solaris /usr/local//lib/perl5/5.00503 /usr/local//lib/perl5/site_perl/5.005/sun4-solaris /usr/local//lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl) at (eval 2) line 3. /usr/local/apache/bin/apachectl start: httpd could not be started -Perl configuration file perl /apsrc/systems/mod_perl/mod_perl-1.24_01/Makefile.PL \ APACHE_SRC=/apsrc/systems/apache/apache_1.3.14/src \ DO_HTTPD=1 \ EVERYTHING=1 \ USE_APACI=1 \ PREP_HTTPD=1 ---Apache configuration file ./configure --prefix=/usr/local/apache \ --verbose \ --with-port=80 \ --logfiledir=/logrpt/apache \ --server-uid=http \ --server-gid=http \ --htdocsdir=/export/www2_root \ --enable-module=so \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=stats
Help:analysis of PerlModule Apache::Registry
hi friends, i am a newcomer to modperl and have managed to start running it with apache on linux.. but now when it comes to coding i find that my previos cgi scripts are running under modperl in the same way. As i understand.there is some improvement in speed since now the perl interpretor is a part of apache. but in addition. how do i start writing perl so as to take advantage of modperl better..?? Plus can anyone explain to me the semantics/usage of the following in my httpd.conf and how i can change it to suit me better. PerlModule Apache::Registry Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader On /Location Thanks, in advance. Samir _ Get Your Free Email At, http://www.rediffmail.com For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html
Re: PerlModule in .htaccess (for auth) faults (possible patch forperl_config.c)
On 22 Aug 2000, Andrew Gideon wrote:
...
My .htaccess file contains:
PerlModule Apache::TAGXSessionAuth
PerlAuthenHandler Apache::TAGXSessionAuth-authen
PerlAuthzHandlerApache::TAGXSessionAuth-authz
After attaching to a child process and getting the segv,
the stack looks like:
(gdb) where
#0 0x107810 in ap_push_array ()
thanks for digging into this andrew.
i think the problem is related to the perl_merge_server_config routine:
#if 0
/* We don't merge these because they're inlined */
mrg-PerlModule = append_arrays(p, add-PerlModule, base-PerlModule);
mrg-PerlRequire = append_arrays(p, add-PerlRequire, base-PerlRequire);
#endif
this means that VirtualHost configs have NULL for both arrays. this is
fine at startup time, since mod_perl only uses the base_server config.
a simple fix is to not push if either is NULL:
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.103
diff -u -u -r1.103 perl_config.c
--- src/modules/perl/perl_config.c 2000/09/26 20:05:22 1.103
+++ src/modules/perl/perl_config.c 2000/09/26 20:59:48
@@ -587,8 +587,11 @@
return NULL;
}
}
-*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+if (cld-PerlModule) {
+*(char **)push_array(cls-PerlModule) = pstrdup(parms-pool, arg);
+}
+
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
perl_section_self_boot(parms, dummy, arg);
@@ -618,7 +621,9 @@
}
}
-*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+if (cls-PerlRequire) {
+*(char **)push_array(cls-PerlRequire) = pstrdup(parms-pool, arg);
+}
#ifdef PERL_SECTIONS
if(CAN_SELF_BOOT_SECTIONS)
Re: Package Lexicals and PerlModule
mgraham ([EMAIL PROTECTED]) said something to this effect:
With the above I expect to be able to call the following in some
handler:
Foo::load_var()
...and $PACKAGE_LEXICAL should still be 'wubba'.
...Except that by calling Foo:load_var() you are setting $PACKAGE_LEXICAL
to undef (by passing in an empty list via ()), rather than retrieving it.
You should do something like:
package Foo;
{ # Block scope this stuff just to ensure that no other subroutine besides
# var can modify $PACKAGE_LEXICAL.
my $PACKAGE_LEXICAL;
sub var {
return
(@_)
? $PACKAGE_LEXICAL = shift
: $PACKAGE_LEXICAL;
}
}
# More of package Foo here...
1;
This will set $PACKAGE_LEXICAL if you pass something in, and return it, or
just return it otherwise. Each child will have its own $PACKAGE_LEXICAL.
(darren)
--
All things are possible, except for skiing through a revolving door.
RE: Package Lexicals and PerlModule
darren chamberlain wrote:
...Except that by calling Foo:load_var() you are setting
$PACKAGE_LEXICAL
to undef (by passing in an empty list via ()), rather than
retrieving it.
Well, actually, I was checking to see if it was set first:
sub load_var {
my $param = shift;
$PACKAGE_LEXICAL = $param if $param;
}
Your example does essentially the same thing, but is interesting
because it puts the sub and the lexical variable in a nested block
scope, and as you say:
Each child will have its own $PACKAGE_LEXICAL.
That's a neat trick! However, for my purposes, I don't want each
child to have a separate $PACKAGE_LEXICAL. I want to set the variable
with the parent process (actually from setup.pl) and I want children
to be able to call the sub without any parameters. And I want the
variable to be visible to subs in the same package, but not to code
outside the package. It's kind of like a class variable without
objects. Maybe it would be clearer with two subs:
package Foo;
my $PACKAGE_LEXICAL;
sub set_var {
$PACKAGE_LEXICAL = shift;
}
sub do_stuff {
# do something with $PACKAGE_LEXICAL;
}
I want to be able to call Foo::set_var('wubba') from startup.pl, and
then call Foo::do_stuff() from some child process.
The weird thing is, this works as I expect when I put "PerlModule Foo"
in httpd.conf, but not when I put "use Foo;" in startup.pl.
Does everybody else use PerlModule to pull in their modules, or
startup.pl?
Michael
Re: Package Lexicals and PerlModule
On Fri, 4 Aug 2000, darren chamberlain wrote: Sharing a variable among children is difficult; you need to use IPC::Sharable or something similar. Not if it's read-only after the fork, which this one appears to be. You can load it with a value at startup and it will be shared. - Perrin
Re: Package Lexicals and PerlModule
On Sun, 30 Jul 2000, mgraham wrote: Under mod_perl, I find inconsistent behaviour. It works fine when a module is loaded via the PerlModule directive in httpd.conf. However when a module is loaded via startup.pl, the package lexicals "forget" their values between calls. [...] The strange thing is that this works when Foo is required in httpd.conf via a "PerlModule Foo" directive. But when Foo is pulled in via a "use Foo" in startup.pl, $PACKAGE_LEXICAL does not keep it's value. This sounds like a bad interaction with PerlFreshRestart and closure variables. Does it work if you turn off PerlFreshRestart? Can you live with that? By the way, PerlFreshRestart is not supposed to be on by default, but using mod_perl compiled as DSO causes similar behavior in recent versions (1.22 on). - Perrin
RE: Package Lexicals and PerlModule
Perrin Harkins wrote: This sounds like a bad interaction with PerlFreshRestart and closure variables. Does it work if you turn off PerlFreshRestart? Can you live with that? Yes! It works with PerlFreshRestart Off. I think you're right - it probably has something to do with the timing of when various bits get compiled and executed. By the way, PerlFreshRestart is not supposed to be on by default, but using mod_perl compiled as DSO causes similar behavior in recent versions (1.22 on). I had it turned on for some reason. Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? Michael
RE: Package Lexicals and PerlModule
On Fri, 4 Aug 2000, mgraham wrote: Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? With PerlFreshRestart turned off, a graceful restart will not reload changed code. You have to do a full stop/start to pick up changes. - Perrin
RE: Package Lexicals and PerlModule
"PH" == Perrin Harkins [EMAIL PROTECTED] writes: PH On Fri, 4 Aug 2000, mgraham wrote: Why should PerlFreshRestart be on, anyway? Ostensibly, it's so you can make sure that your modules can survive a soft restart, but can't you also gather that from 'apachectl graceful'? PH With PerlFreshRestart turned off, a graceful restart will not reload PH changed code. You have to do a full stop/start to pick up changes. Unless you are using mod_perl as a DSO in which case PerlFreshRestart is irrelevent -- it is always freshly started. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Package Lexicals and PerlModule
I'm experiencing a strange variable scope issue.
Normally, I expect that lexical 'my' vars declared at the package
scope (i.e. at the top of a file), should be visible to subroutines
declared in the same package, and should maintain their values between
calls to those subroutines.
Under mod_perl, I find inconsistent behaviour. It works fine when a
module is loaded via the PerlModule directive in httpd.conf. However
when a module is loaded via startup.pl, the package lexicals "forget"
their values between calls.
# Foo.pm
package Foo;
use strict;
my $PACKAGE_LEXICAL;
warn "I'm being loaded";
sub load_var {
my $param = shift;
$PACKAGE_LEXICAL = $param if $param;
warn "PACKAGE_LEXICAL: $PACKAGE_LEXICAL\n";
}
1;
# startup.pl
use Foo;
Foo::load_var('wubba');
With the above I expect to be able to call the following in some
handler:
Foo::load_var()
...and $PACKAGE_LEXICAL should still be 'wubba'.
The strange thing is that this works when Foo is required in
httpd.conf via a "PerlModule Foo" directive. But when Foo is pulled
in via a "use Foo" in startup.pl, $PACKAGE_LEXICAL does not keep it's
value.
In both cases, Foo.pm gets loaded twice at startup, (there are two
"I'm being loaded messages" in the logs which I'm assuming this is
because PerlFreshRestart is On by default). Also in both cases,
Foo.pm is being loaded by uid 0, so I'm assuming this is not a
parent/child sharing problem.
Can anybody see what I'm missing?
The Eagle book suggests that it's best to load modules from startup.pl
rather than httpd.conf. Is this not such a good idea after all?
Michael
Re: Package Lexicals and PerlModule
On Sun, 30 Jul 2000, mgraham wrote: Normally, I expect that lexical 'my' vars declared at the package scope (i.e. at the top of a file), should be visible to subroutines declared in the same package, and should maintain their values between calls to those subroutines. If you are running perl v5.6 or later, I think you can use "our" instead of "my" and it will do what you want it to do. As for why it acts this way, I'm not sure...perhaps someone else on this mailing list can shed some light on this issue. -Philip Mak ([EMAIL PROTECTED])
Re: PerlModule/Require didn't work ??
On Thu, 16 Dec 1999 [EMAIL PROTECTED] wrote: hi, I was wondering why the PerlModule and perlRequire didn't work for me. I have a fresh installation of : apache 1.3.9 + mod_perl 1.21 (that is bundled in RedHat6.1), what was my surprise to see that when I try to use something like : PerlRequire .../startup.pl or PerlModule Apache::DBI Apache::ASP the Apache won't start. When I start the apache i.e. : /etc/rc.d/init.d/httpd start I get .. [OK] , but nothing started nothing even in the error_log :"( (LogLevel debug). I missed something or WHAT ?!? there have been several messages over the past 1-2 weeks on how to diagnose the problem, did you try any of them? I thought that it was 'cause now by default if Apache find suEXEC it runs in suEXEC-mode, but I moved suEXEC and it dosen't use it then. Another surprice was that if I go .../perl-status .. Loaded Modules ... I see CGI there, but I didn't point to it in .conf files.?!?! Apache::Status uses CGI.pm, or Apache::Request if you have it installed.
Re: PerlModule/Require didn't work ??
This is the same problem I've been struggling with. What has fixed it for me is building Apache and mod_perl from the tar archives and linking Apache statically (no .so's). I haven't investigated much further, but even after I built Perl, Apache, and mod_perl by hand it still happened. Only when I switch to a non-DSO Apache did it work for me. -bill At 03:39 PM 12/16/99 +, [EMAIL PROTECTED] wrote: hi, I was wondering why the PerlModule and perlRequire didn't work for me. I have a fresh installation of : apache 1.3.9 + mod_perl 1.21 (that is bundled in RedHat6.1), what was my surprise to see that when I try to use something like : PerlRequire .../startup.pl or PerlModule Apache::DBI Apache::ASP the Apache won't start. When I start the apache i.e. : /etc/rc.d/init.d/httpd start I get .. [OK] , but nothing started nothing even in the error_log :"( (LogLevel debug). I missed something or WHAT ?!? I thought that it was 'cause now by default if Apache find suEXEC it runs in suEXEC-mode, but I moved suEXEC and it dosen't use it then. Another surprice was that if I go .../perl-status .. Loaded Modules ... I see CGI there, but I didn't point to it in .conf files.?!?! Thanx alot in advance = iVAN [EMAIL PROTECTED] =
Re: Win32+PerlModule works !!!
Thanks a lot, Randy!!! I recompiled mod_perl with that flag, and now PerlModule/PerlRequire/Use ... work! Apache comes up, and everything seems fine so far! But I don't know how this flag influences whatever. Apache loads all APache modules twice. This flag disables all PerlRequire and PerlModule statements on the first load, so they can succeed on the second load. Without that flag, the second load fails. If that works for all Win32-systems and has no bad side-effect, I suggest that it should be inserted into the distributed 'mod_perl.h'-file - thinking I'm not the only one having this problem ... I have suggest to make this default for NT when I send this patch to Doug, but he decided, to make it conditional. Gerald
Re: Win32+PerlModule works !!!
Have you been able to install it as a NT Service? I can only run 1.3.9/1.2.21 from the command line. 1.3.6/1.2.21 are working fine. :( I hate NT. John [EMAIL PROTECTED]
RE: Win32+PerlModule works !!!
Have you been able to install it as a NT Service? I can only run 1.3.9/1.2.21 from the command line. 1.3.6/1.2.21 are working fine. :( I hate NT. Did you try to compile mod_perl with #define PERL_STARTUP_DONE_CHECK 1 at the top of the mod_perl.h? This may solve your problem. Gerald
Re: Win32+PerlModule works !!!
Did you try to compile mod_perl with #define PERL_STARTUP_DONE_CHECK 1 at the top of the mod_perl.h? This may solve your problem. Yes, without that define, DBI breaks and I can't run from the command line without -X Very frustrating, but no more so than the typical experience of using NT. John [EMAIL PROTECTED]
RE: Win32+PerlModule works !!!
Yes, without that define, DBI breaks and I can't run from the command line without -X Very frustrating, but no more so than the typical experience of using NT. Did you first uninstall the old one (Apache -u), before installing the new one? Does the error log contains any hints? Gerald
Re: Win32+PerlModule works !!!
FWIW, I have Randy Kobes' modperl/apache distribution installed on NT 4.0 as a service. It appears to execute successfully using ODBC against an Access database locally and a DB2 database on a remote machine. John D Groenveld [EMAIL PROTECTED] on 12/15/99 03:28:23 PM To: "Gerald Richter" [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: John Arnold/DTC) Subject: Re: Win32+PerlModule works !!! Did you try to compile mod_perl with #define PERL_STARTUP_DONE_CHECK 1 at the top of the mod_perl.h? This may solve your problem. Yes, without that define, DBI breaks and I can't run from the command line without -X Very frustrating, but no more so than the typical experience of using NT. John [EMAIL PROTECTED]
Re: Win32+PerlModule works !!!
- Original Message - From: John D Groenveld [EMAIL PROTECTED] To: Rolf Ohnmacht [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, December 15, 1999 4:24 PM Subject: Re: Win32+PerlModule works !!! Have you been able to install it as a NT Service? I can only run 1.3.9/1.2.21 from the command line. 1.3.6/1.2.21 are working fine. :( I hate NT. John No, because on the Apache installation guide it was described that one should have a special "install shield" tool to get the NT Service to work. But I start Apache from a simple command shell and I like it much more than do some "clicky-clicky" to get into the services folder and do other clicks to stop/start/restart the server. Using command-lines it's only Ctr-C and DblClick! This is one of many reasons I like Apache: I spent some time with IIS and ASP and hated IIS because of its overdimensionaled graphical interface. Then I went to Apache and found that the whole thing can be done within one editable config file - http.conf ... Why do you wish to have the Apache as NT Service to run? If you have good arguments, let me know! Rolf
Win32+PerlModule works !!!
- Original Message - From: Randy Kobes [EMAIL PROTECTED] To: Rolf Ohnmacht [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, December 14, 1999 2:32 AM Subject: Re: Win32+modperl+EmbPerl - some questions ... 1.) 'PerlModule' ( eg. srm.conf ) or 'use HTML::Embperl' ( startup.pl) both don't work! But if I leave it - no problem! Is this a special "Win32-behaviour"? Hi, I've seen a similar problem before on Win32 - try compiling mod_perl with the PERL_STARTUP_DONE_CHECK flag set, which you can do by adding #define PERL_STARTUP_DONE_CHECK 1 to the top of src/modules/perl/mod_perl.h. best regards, Randy Kobes Thanks a lot, Randy!!! I recompiled mod_perl with that flag, and now PerlModule/PerlRequire/Use ... work! Apache comes up, and everything seems fine so far! But I don't know how this flag influences whatever. If that works for all Win32-systems and has no bad side-effect, I suggest that it should be inserted into the distributed 'mod_perl.h'-file - thinking I'm not the only one having this problem ... Rolf
Re: Seg fault on fork w/ PerlModule
can you get a stacktrace with gdb? see the SUPPORT doc for hints.
On Tue, 16 Nov 1999, Tony Demark wrote:
I have compiled the following:
Apache 1.3.9
mod_perl 1.21 (PERL_AUTHEN PERL_LOG PERL_STACKED_HANDLERS)
on:
Ultra 10
Solaris 7
with:
gcc 2.95.2 19991024
perl 5.005_03
When starting an httpd process with a 'PerlModule' defined in the conf file,
the process will seg fault when it attempts to fork:
open("/opt/apache/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0644) = 3
fcntl(3, F_DUPFD, 0x000F) = 16
close(3)= 0
chdir("/") = 0
fork() = 16024
Incurred fault #6, FLTBOUNDS %pc = 0xD002
siginfo: SIGSEGV SEGV_MAPERR addr=0xD002
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0xD002
*** process killed ***
However, comment out the 'PerlModule' statement, and the process forks fine
and exits:
open("/opt/apache/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0644) = 3
fcntl(3, F_DUPFD, 0x000F) = 16
close(3)= 0
chdir("/") = 0
fork() = 16030
llseek(0, 0, SEEK_CUR) = 101628
_exit(0)
I didn't see anything about this on the maillist... get anyone give me an
idea of where I should at least start to track down this problem?
Thanks,
- Tony
Re: Seg fault on fork w/ PerlModule
Tony Demark wrote: I have compiled the following: Apache 1.3.9 mod_perl 1.21 (PERL_AUTHEN PERL_LOG PERL_STACKED_HANDLERS) [cut] When starting an httpd process with a 'PerlModule' defined in the conf file, the process will seg fault when it attempts to fork: [cut] It is well known now that there is a problem with mod_perl as a DSO with these versions. Have you tried statically linking mod_perl into Apache? There's been a fair amount of discussion about all this, actually.
Seg fault on fork w/ PerlModule
I have compiled the following:
Apache 1.3.9
mod_perl 1.21 (PERL_AUTHEN PERL_LOG PERL_STACKED_HANDLERS)
on:
Ultra 10
Solaris 7
with:
gcc 2.95.2 19991024
perl 5.005_03
When starting an httpd process with a 'PerlModule' defined in the conf file,
the process will seg fault when it attempts to fork:
open("/opt/apache/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0644) = 3
fcntl(3, F_DUPFD, 0x000F) = 16
close(3)= 0
chdir("/") = 0
fork() = 16024
Incurred fault #6, FLTBOUNDS %pc = 0xD002
siginfo: SIGSEGV SEGV_MAPERR addr=0xD002
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0xD002
*** process killed ***
However, comment out the 'PerlModule' statement, and the process forks fine
and exits:
open("/opt/apache/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0644) = 3
fcntl(3, F_DUPFD, 0x000F) = 16
close(3)= 0
chdir("/") = 0
fork() = 16030
llseek(0, 0, SEEK_CUR) = 101628
_exit(0)
I didn't see anything about this on the maillist... get anyone give me an
idea of where I should at least start to track down this problem?
Thanks,
- Tony
