Mr. Foertsch, that was a wonderful reply. Just what the doctor ordered. Thanks.
> If you are using the prefork MPM (as you probably do) you can still > manipulate the environment without affecting other requests. But you > have to use the C-level functions. There is a module called Env::C on > CPAN that provides a Perl interface to them. Yes, I am using the prefork MPM. I have put together a test of this, and Env::C works as advertised. For those variables that need to be passed to the subprocess, lines like this suffice: foreach my $var_name ( qw/DB_SVR TEST1 TEST2/ ) { Env::C::setenv( $var_name, $ENV{ $varname}, 1); } Very simple. Of course there's scant documentation on the required environment variables in most of the scripts that I'll be calling, but that's a different matter.... > Let's have a look at the reason for this behavior first. It's always > better to know what you are doing. Apache 2.x can use various MPMs. > Some of them use threads instead of processes to achieve parallelism. > Now, the environment is a process global resource. So, if > those values are changed all threads are affected. This is surely no > what you want. When you say that the environment is a global process, global to what? Each forked process has its own environment, doesn't it? It seems to me from the brief piece in the User Guide about this and what you've said, that threaded environments are the real problem here. In the case of threaded environments, the environment is shared among all threads, whereas forked processes can and do have distinct environments per process. Is this correct? That means (as suggested in the relevant source comments) that a solution for the forked MPM would be much easier than for those that are threaded. Right? > Therefore there is a request specific data structure called > subprocess_env where environment variables for CGI scripts > are kept. If you use the Apache interface to spawn subprocesses > (Apache2::SubProcess) you'll notice that variables set in > subprocess_env appear as environment variables of the spawned > process. Under mod_perl %ENV is tied to $r->subprocess_env. Do you need to explicitly set environment variables in subprocess_env to have them show up in the environment of the forked process, or do they get passed automatically? Just because I wanted to think this thing through... if you fork off a Perl script, for example, and that Perl script forks off another process, that is done using standard forking so the environment is passed to the forked process. That was what my experimentation showed up anyway. Eric > -----Original Message----- > From: Torsten Foertsch [mailto:[EMAIL PROTECTED] > Sent: Friday, August 15, 2008 3:15 PM > To: modperl@perl.apache.org > Cc: Berg, Eric > Subject: Re: mp2, IPC::Run3 && Environment Variables giving > "variable not set" error > > On Fri 15 Aug 2008, Berg, Eric wrote: > > This issue of the environment variables' not being passed to forked > > processes is turning into a fairly substantial problem for me. We > > have a number of places in our code -- both the modules that are > > tightly controlled and fairly easy to manage, as well as a bunch of > > scripts and CGI's that use them -- that use system or backticks > > (sometimes via IPC::Run3) to get info from external tools. > > > > Does anybody know anything about this issue or about the code > > involved? How difficult would it be to address this? I took a look > > at the code in modperl_env.c as suggested in the docs, but > I'm a Perl > > guy, not a C guy. > > > > This is a deal killer for us. > > > Therefore there is a request specific data structure called > subprocess_env where environment variables for CGI scripts > are kept. If you use the Apache interface to spawn subprocesses > (Apache2::SubProcess) you'll notice that variables set in > subprocess_env appear as environment variables of the spawned > process. Under mod_perl %ENV is tied to $r->subprocess_env. > > > Torsten > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.