NAME

Troubleshooting mod_perl problems

Description

Frequently encountered problems (warnings and fatal errors) and their troubleshooting.

Building and Installation

Configuration and Startup

Shutdown and Restart

Code Parsing and Compilation

Runtime

C Libraries Don't See %ENV Entries Set by Perl Code

For example some people have reported problems with DBD::Oracle (whose guts are implemented in C), which doesn't see environment variables (like ORACLE_HOME, ORACLE_SID, etc.) set in the perl script and therefore fails to connect.

The issue is that the C array environ[] is not thread-safe. Therefore mod_perl 2.0 unties %ENV from the underlying environ[] array under the perl-script handler.

The DBD::Oracle driver or client library uses getenv() (which fetches from the environ[] array). When %ENV is untied from environ[], Perl code will see %ENV changes, but C code will not.

The modperl handler does not untie %ENV from environ[]. Still one should avoid setting %ENV values whenever possible. And if it is required, should be done at startup time.

In the particular case of the DBD:: drivers, you can set the variables that don't change ($ENV{ORACLE_HOME} and $ENV{NLS_LANG} in the startup file, and those that change pass via the connect() method, e.g.:

my $sid      = 'ynt0';
my $dsn      = 'dbi:Oracle:';
my $user     = 'username/password';
my $password = '';
$dbh = DBI->connect("$dsn$sid", $user, $password)
    or die "Cannot connect: " . $DBI::errstr;

Also remember that DBD::Oracle requires that ORACLE_HOME (and any other stuff like NSL_LANG stuff) be in %ENV when DBD::Oracle is loaded (which might happen indirectly via the DBI module. Therefore you need to make sure that wherever that load happens %ENV is properly set by that time.

Maintainers

Maintainer is the person(s) you should contact with updates, corrections and patches.

• Stas Bekman

Authors

• Stas Bekman

Only the major authors are listed above. For contributors see the Changes file.