• Most common thing I do in <Perl> tags: use lib (...)
• Funniest thing I've ever done in a <Perl> tag: assert that the httpd is not being started by root. Because our typical production environment (from which we template our development configs) will setuid to httpd.nobody (fairly standard), but developers' httpds should run under their own UIDs (and if not started by root, they can't setuid... so all is happy!).

As to your note at the end, that you are considering preopening a DBI connection: don't do that. DBI isn't fork-safe in that manner (at best, you'd be able to use the connection in one of your subprocesses). Instead, you should use Apache::DBI, which lets your subprocesses connect once, on the first request, and hold the connection open for future requests. The connections do have to be one per subprocess, though, so no connecting before the fork and inheriting connections... sorry.

As to your note at the end, that you are considering preopening a DBI connection: don't do that. DBI isn't fork-safe in that manner

You are absolutely right in your statement about opening DBI connections at startup and leaving them open to be inherited by the child processes. That causes all kinds of problems.

But it is perfectly safe to open a DBI connection at startup, use it to do some configuration, and then closing it before the fork. I have a feeling that is what bsb was questioning.

- Cees

1. Do you use <Perl> sections?

I used to several years ago...

If I were you I woud stay away from any complex configurations using <Perl> sections. There are better ways to do it. All <Perl> sections really give you is the ability to dynamically configure the apache server, and there are other ways of achieving that. It sounds really cool and powerful, but it ends up being a lot more difficult and cumbersome than the other methods.

Your best bet is probably using a templated system that generates your config files right before the server starts. This gives you all the power that the <Perl> sections give you in dynamically configuring your server.

Another often overlooked module is the mod_macro module. This can also greatly simplify your config files.

Also, <Perl> sections are not supported under mod_perl2 yet.

One question... Why do you have mod_perl enabled on your main web server? If you have enough sites to require an automated config system, then you should really have a proxied mod_perl server. Personally I run 3 apache servers. A frontend server for static content with mod_proxy enabled, and a mod_perl backend and mod_php backend. I have one include file for each VirtualHost that is used by all three servers (by heavily using IfModule mod_perl.c sapi_apache2.c). Of course this setup precludes me from using <Perl> sections all together, since the frontend and mod_php servers can't do <Perl> sections...

It sounds really cool and powerful, but it ends up being a lot more difficult and cumbersome than the other methods

I've spent a bit over a day playing around and I'm inclined to believe you. Thanks for your response.

Your best bet is probably using a templated system that generates your config files right before the server starts

Interesting. I'd considered doing the template processing at "deployment time" but not during server startup. This could be what I'm after.

Why do you have mod_perl enabled on your main web server?
I don't, it just sounds that way. My setup is like yours without mod_php.

Thanks again, Brad

Re: Memory usage on reload and graceful -- still broken?
by Doug MacEachern

>  You got me!  I have <Perl> sections ... but I didn't know
>  it was such a crime.  Pretty bizarre behavior if you ask me.

it's not a crime, but if you're running Perl code during restart there's a
strong chance you'll be growing the server size.  i agree 1M is bizarre
though.