SPUG: Apache and Modules

Chris Sutton chris at chriskate.net
Wed Jan 23 22:31:56 CST 2002


I've been doing mod_perl stuff for quite a while and though I hate doing 
this, the only way I've found to make sure Apache is running the correct 
versions of perl code (using a cached version vs. one just loaded off disk) 
is to restart the server.  Do a full stop and then start, not just HUP.

Not sure how this fits into what you are trying to do, but when weird stuff 
starts happening between requests, I find its time to restart the server.

Whenever I release development code to a production server, if it's mod_perl, 
I always restart apache on the production machine.

On Wednesday 23 January 2002 09:33 am, you wrote:
> Friends,
> 	I have a question about how Apache Mod_Perl caches modules, which I can't
> find on the web anywhere.
>
> 	The situation I'm in is that I recently started using CVS and found that
> it was easier to have a cvs Modules repository where I keep my custom
> modules, so they can be easily replicated to my production web server. 
> Older versions of these same modules exist in the standard modules
> directory, '/usr/lib/perl5/site_perl/5.005/i386-linux/'.  	It appears that
> the module that gets cached by the httpd instance is dependant on weather
> the first script it runs has the use lib '../Modules' line in it or not. 
> If it does it seems to cache the module from the cvs fed directory, and if
> not it caches the one from the standard modules directory.
> 	I've changed my startup.pl to include use lib 'my cvs modules directory',
> which seems to solve my problem, but I'm not sure.
>
> 	My question is thus: In order to more fully understand the inner workings
> of the system, can someone describe the rules Apache uses for caching
> modules?  Does the behavior that I described make sense, or do y'all think
> I'm missing something?
>
> Thanks,
> Peter Darley
>
> P.S.  I understand that having packages of the same name in different
> places is probably not good, and I'll clean it up in the future, but
> because of time considerations I don't have a whole lot of choice for now.
>
>
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
>       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
>   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
>  For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
>      Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/





More information about the spug-list mailing list