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.
