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 [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 use Foo::Bar qw ( ... whatever you want to import ... ); -- WBR, Mike P. Mikhailov mailto: [EMAIL PROTECTED] ICQ:280990142 I believe in God, only I spell it Nature.
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 use Foo::Bar qw ( ... whatever you want to import ... ); 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?
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 > > > > > > use Foo::Bar qw ( ... whatever you want to import ... ); > > > > 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?
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 > > > use Foo::Bar qw ( ... whatever you want to import ... ); > > > -- > 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
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
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: 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 > > > use CGI; > > > 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
Problems with PerlModule
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 use CGI; everything works fine. The CGI module is only an example. I have similar problems with several other modules. Any ideas? --Nikolaus
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 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 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:
> 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 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 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
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 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 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:> 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 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
PerlModule hell - questions and comments
I'm posting this to the modperl list as well as embperl in hope that
someone there can answer some questions.
I've been trying to get the latest Embperl beta working on MacOS X
(although apparently the problems I'm experience occur on some other
operating systems as well). Embperl 2.0b7, Apache 1.3.23, mod_perl
1.26. Gerald's going on a well-deserved vacation starting about now,
but I think some of these questions are not specific to Embperl.
1. *Why* are the apache config files executed twice (completely with
loading and unloading all the modules)? At least one module even has
code to check and only do an initialization the second time it is
called!
2. Why doesn't mod_perl force the Perl interpreter to restart when
that happens, so that the initialization the second time is identical
to the first time?
3. Why does mod_perl only delete $INC entries if there is a
directive in the config file?
4. Why doesn't deleting the $INC entry force the second Require
(executed as a result of the PerlModule command) to actually load the
perl library again?
Here's what I believe is *supposed* to happen with Embperl.
mod_perl is loaded
PerlModule Embperl causes Embperl.pm to load, which calls an init
function, which calls ap_add_module which causes Embperl to be
installed as a full-fledged apache module (complete with added syntax
for the config file).
Here's what *actually* happens.
On the first pass through the config file, everything happens exactly
as described above.
On the second pass (more on that in a minute) through the config
file, mod_perl does a Require of Embperl, Embperl.pm has already been
loaded, so it isn't executed, the init call doesn't get called, the
module doesn't get loaded, everything breaks.
Quite by accident I discovered that if I put the following code in my
config file, things got a little bit better.
Now on the second pass through the config file, mod_perl calls delete
$INC{'Embperl.pm'} and the require loads the file again. At least in
theory.
That actually got me to the point where Embperl runs. But oddly, the
config file extensions don't get parsed (e.g. I can't use any of
Embperl's extensions to the config file syntax). The module isn't
completely registered.
So, to make a long story short. I had to do a number of things to
make this work. Some are Embperl specific, some I think relate to
problems with the mod_perl architecture.
1. In Embperl's Apache cleanup handler, always unload embperl.c, even
if mod_perl isn't loaded dynamically.
2. In Embperl's init routine, *always* call ap_add_module, even if we
weren't called from the Embperl.pm startup.
3. In the config file, explicitly call Embperl::Init in
tags. You have to do this because on the second pass through the
config file it isn't called at the right times. It will get
correctly called when PerlHandler Embperl is found, but that's too
late for some config file directives.
That all sounds confusing, here's a trace (of the working version) to
clear it up (hah!). First, here's my section in the config
file.
print STDERR " Before 1\n";
print STDERR '#', $INC{"Embperl.pm"}, "#\n";
print STDERR " Before 2\n";
PerlModule Embperl
print STDERR " After 1\n";
print STDERR '#', $INC{"Embperl.pm"}, "#\n";
Embperl::Init();
print STDERR " After 2\n";
and the trace
$ MOD_PERL_TRACE=all sudo /usr/local/apache/bin/httpd -X
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
loading perl module 'Apache'...loading perl module
'Apache::Constants::Exports'...ok
ok
loading perl module 'Tie::IxHash'...ok
Okay, cool we've loaded and started perl. Now we check and see if
$INC has been set for Embperl.
Before 1
##
Before 2
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
loading perl module 'Apache'...ok
And now we do the PerlModule Embperl. It correctly calls the init
functions, which correctly call add_module.
PerlModule: arg='Embperl'
loading perl module 'Embperl'...
## called embperl_INit (0x3C40EC)
## 1 calling add_module
## 2 calling add_module
ok
bootstrapping sections: arg=Embperl, keys=8
loading perl module 'Apache'...ok
loading perl module 'Tie::IxHash'...ok
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
perl_section:
mod_perl: delete $INC{'Embperl.pm'} (klen=10)
Look ma, it just deleted the $INC entry so if we require it again it
will load again. Maybe.
loading perl m
Re: PerlModule not updating %INC
At 11.00 -0500 11/21/2001, Perrin Harkins wrote: > > >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
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
> -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
> 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: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-modperl&m=100510779912574&w=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
> I wonder if this has something to do with the multiple init thing
>
> http://marc.theaimsgroup.com/?l=apache-modperl&m=100510779912574&w=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: 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-modperl&m=100510779912574&w=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
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 and >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 > > >SetHandler perl-script >PerlHandler My::Special::Module > > >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 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: PerlModule not updating %INC
> 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. ...and that's why you shouldn't use StatINC on a production server. There is no magic about pre-loading: %INC should be set and StatINC will overwrite it if you change the file, ruining your shared memory. 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?) - Perrin
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 and 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 SetHandler perl-script PerlHandler My::Special::Module 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.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 handlers? > > >SetHandler perl-script >PerlModule My::Special::Module >PerlHandler My::Special::Module > > > >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 and 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 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
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 handlers? SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module 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 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
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 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: 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
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 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.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
> 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
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 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: Modules `use`d by PerlModule vanishing after startup? (resend)
[EMAIL PROTECTED] (Stephen Clouse) wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Fri, Aug 24, 2001 at 03:46:07PM -0700, ___cliff rayman___ wrote: >> 'PerlModule' in httpd.conf and 'use' in startup.pl perform the same >> purpose. if you are going to 'use' in startup.pl, comment out the >> PerlModule directive in httpd.conf. > >Except PerlModule is the only way to register Apache configuration >directives, which we define several, so we have to do it that way. But >the program doesn't work without the use in startup.pl, even though >PerlModule should load everything. Bizarre Hmm, as far as I know there are only 2 differences between 'PerlModule Foo' and 'use Foo;'. Config directive processing is one, and the other is that if the perl interpreter hasn't already started, PerlModule will delay loading the module until after it's started. So you might try putting an empty section in your httpd.conf prior to the PerlModule directive. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Modules `use`d by PerlModule vanishing after startup? (resend)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Aug 24, 2001 at 03:46:07PM -0700, ___cliff rayman___ wrote: > 'PerlModule' in httpd.conf and 'use' in startup.pl perform the same purpose. > if you are going to 'use' in startup.pl, comment out the PerlModule directive > in httpd.conf. Except PerlModule is the only way to register Apache configuration directives, which we define several, so we have to do it that way. But the program doesn't work without the use in startup.pl, even though PerlModule should load everything. Bizarre > i'm not sure why you are having the other problems, might have something to > do with the order than things are being loaded and initialized. if the 'use' in > startup.pl works fine, then you should stick with that. Guess I'll have to live with the redefined subroutine warnings, unless someone else knows where the bug lies - -- 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/AwUBO4bg8gOGqGs0PadnEQJu2QCgp9LKHIsVnjE6HKUZpInik8NhtcgAn18v taiq7P/qMMTOpZT9fXXt3WWF =QwT9 -END PGP SIGNATURE-
Re: Modules `use`d by PerlModule vanishing after startup? (resend)
Stephen Clouse wrote: > 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. 'PerlModule' in httpd.conf and 'use' in startup.pl perform the same purpose. if you are going to 'use' in startup.pl, comment out the PerlModule directive in httpd.conf. i'm not sure why you are having the other problems, might have something to do with the order than things are being loaded and initialized. if the 'use' in startup.pl works fine, then you should stick with that. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Modules `use`d by PerlModule vanishing after startup? (resend)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't get a single response to this the first time around, so I'm resending it. This remains an issue for me. 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/AwUBO4bXeAOGqGs0PadnEQLfdACff866KfM7hpQFsTyn5ajB+LxN/MIAnAwK lPpIGKwIlCaWZqL/gNSMkIdM =Fwes -END PGP SIGNATURE-
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/
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
[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
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
___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
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/
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
> 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
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
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-
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/
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
PerlModule vs "use" in a 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: use Apache::Foo; Or this: PerlModule Apache::Foo I would expect the two to behave the same, but they don't! The "use" in the 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/
RE: [bug] PerlModule reloads modules twice on start
I noticed this behavior as well. > I've noticed an inconcistency between PerlModule and use() (and > PerlRequire and require()).
[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/ 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 SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all PerlSendHeader On 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)
PerlModule in .htaccess (for auth) faults (possible patch for perl_config.c)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (will trillich) writes:
> from http://perl.apache.org/current/htdocs/manual/mod/mod_perl.html
> PerlModule directive
>
> Description: List of Perl modules
>
> Syntax: PerlModule Arg1 x n (ITERATE)
> PerlSyntax: push @PerlModule, $arg1
> Context: Allowed in *.conf anywhere and in .htaccess
> Override: Any other than None
> Status: Extension
> Module: mod_perl
>
> yet when i put 'PerlModule Serensoft::Auth' into
> the .htaccess file i consistently got
> [notice] child pid 30127 exit signal Segmentation fault (11)
>
> moving it back into the /etc/apache/httpd.conf file,
> all is sparkly again.
I'm seeing the same thing (or something quite similar) here:
Solaris 2.7/Sparc
Apache 1.3.12 (Stronghold)
mod_perl/1.24
egcs-1.1.1
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 ()
#1 0x66a68 in perl_cmd_module ()
#2 0x10f840 in invoke_cmd ()
#3 0x10ff74 in ap_handle_command ()
#4 0x110054 in ap_srm_command_loop ()
#5 0x110aa8 in ap_parse_htaccess ()
#6 0x128ea0 in directory_walk ()
#7 0x12a784 in process_request_internal ()
#8 0x12ad3c in ap_process_request ()
#9 0x11e918 in child_main ()
#10 0x11ec90 in make_child ()
#11 0x11eda8 in startup_children ()
#12 0x11f694 in standalone_main ()
#13 0x120288 in main ()
If PerlModule is placed into the httpd.conf file,
all works well.
In further debugging, one thing I noted was that,
at the point ap_push_array() in perl_cmd_module()
is called, the cls structure looks like:
$3 = {PerlPassEnv = 0x522710, PerlRequire = 0x0, PerlModule = 0x0,
PerlTaintCheck = 0, PerlWarn = 0, FreshRestart = 0, PerlInitHandler = 0x0,
PerlPostReadRequestHandler = 0x0, PerlTransHandler = 0x0,
PerlChildInitHandler = 0x0, PerlChildExitHandler = 0x0, PerlRestartHandler = 0x0,
PerlOpmask = 0x0, vars = 0x522730}
I'm pretty sure that PerlModule=0 is wrong. When I place a
PerlModule directive into httpd.conf, it is not null (which
is why it works then).
I've a version 1.21 mod_perl also running, and this problem
doesn't occur there. I noticed that it only pushes the module
onto the PerlModule vector if perl is not already running. That
makes sense, as the vector is used in perl_startup() to determine
what to perl_require_module(). However, if perl was running,
the perl_require_module() is already done!
So I tried a return immediately after perl_require_module()'s
successful return in perl_cmd_module(). That appears to have
solved the problem.
But I'm very unfamiliar with this code, so I don't know that
this is the proper fix. Anyone else?
- Andrew
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/
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
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 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
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
mgraham ([EMAIL PROTECTED]) said something to this effect:
> 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.
Sharing a variable among children is difficult; you need to use IPC::Sharable
or something similar. There is an example in the Apache::Session perldocs of
using a "session" to store global data that gets shared among the children
as well.
The problem with sharing stuff between the parent and children, if I
understand it correctly, is that once a child forks, it has a copy of the
variable, not a reference to it. So, modifications to this copy affect that
child only.
I've never gotten the shm version to work, but I have gotten the
Apache::Session version to work. This is straight from the perldoc:
use Apache;
use Apache::Session::File;
use DBI;
use strict;
my %global_data;
eval {
tie %global_data, 'Apache::Session::File', 1,
{Directory => '/tmp/sessiondata'};
};
if ($@) {
die "Global data is not accessible: $@";
}
my $dbh = DBI->connect($global_data{datasource},
$global_data{username}, $global_data{password}) || die $DBI::errstr;
undef %global_data;
#program continues...
Pretty useful stuff.
(darren)
--
I'd rather have my own game show than enough votes to become president.
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
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
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])
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: Getting PerlSetVar's at PerlModule time...
On Thu, 27 Jan 2000, Matt Sergeant wrote:
> Am I just stupid, or can you not get at PerlSetVar's at server startup time?
>
> I've tried:
>
> Apache->request->dir_config (segfaults)
> Apache->server->dir_config (segfaults)
> and
> Apache::dir_config (script stops, but httpd continues...)
> Apache::dir_config(undef, 'Var') (segfaults)
>
> This is on the latest cvs version. Should I drop back to 1.21?
support for this wasn't added until post-1.21:
add per-server PerlSetVar variables, accessed using
Apache->server->dir_config or $r->server->dir_config.
$r->dir_config merges them with per-directory variables.
[Eric Cholet <[EMAIL PROTECTED]>]
I just tried it for the first time, core dump here too, patch below
fixes..
--- Apache.xs 1999/12/30 19:22:48 1.84
+++ Apache.xs 2000/01/28 04:55:13
@@ -1847,6 +1847,7 @@
server_rec *s;
CODE:
+RETVAL = Nullsv;
if(r && r->per_dir_config) {
c = (perl_dir_config *)get_module_config(r->per_dir_config,
&perl_module);
Getting PerlSetVar's at PerlModule time...
Am I just stupid, or can you not get at PerlSetVar's at server startup time? I've tried: Apache->request->dir_config (segfaults) Apache->server->dir_config (segfaults) and Apache::dir_config (script stops, but httpd continues...) Apache::dir_config(undef, 'Var') (segfaults) This is on the latest cvs version. Should I drop back to 1.21? Apache 1.3.11 mod_perl cvs (27/1/2000) Perl 5.00503 -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
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] >=
PerlModule/Require didn't work ??
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 !!!
- 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
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 !!!
> > 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 !!!
> 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 !!!
> 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 !!!
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 !!!
> > 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
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
I failed to mention that I am *NOT* compiling mod_perl as a DSO - everything
is done statically.
My apologies.
- Tony
In message <[EMAIL PROTECTED]>, "Tony Demark" writes:
>
>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
