Troubleshooting mod_perl problems
Frequently encountered problems (warnings and fatal errors) and their troubleshooting.
httpd-2.0 is not very helpful at telling which device has run out of precious space. Most of the time when you get an error like:
(28)No space left on device: mod_rewrite: could not create rewrite_log_lock
it means that your system have run out of semaphore arrays. Sometimes it's full with legitimate semaphores at other times it's because some application has leaked semaphores and haven't cleaned them up during the shutdown (which is usually the case when an application segfaults).
Use the relevant application to list the ipc facilities usage. On most Unix platforms this is usually an ipcs(1) utility. For example linux to list the semaphore arrays you should execute:
ipcs(1)
% ipcs -s ------ Semaphore Arrays -------- key semid owner perms nsems 0x00000000 2686976 stas 600 1 0x00000000 2719745 stas 600 1 0x00000000 2752514 stas 600 1
Next you have to figure out what are the dead ones and remove them. For example to remove the semid 2719745 execute:
% ipcrm -s 2719745
Instead of manually removing each (and sometimes there can be many of them), and if you know that none of listed the semaphores is really used (all leaked), you can try to remove them all:
% ipcs -s | perl -ane '`ipcrm -s $F[1]`'
httpd-2.0 seems to use the key 0x00000000 for its semaphores on Linux, so to remove only those that match that key you can use:
0x00000000
% ipcs -s | perl -ane '/^0x00000000/ && `ipcrm -s $F[1]`'
Notice that on other platforms the output of ipcs -s might be different, so you may need to apply a different Perl one-liner.
ipcs -s
Update DBI to at least version 1.31.
See the Apache::PerlSections manpage.
%ENV
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.
DBD::Oracle
ORACLE_HOME
ORACLE_SID
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.
environ[]
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.
getenv()
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.:
DBD::
$ENV{ORACLE_HOME}
$ENV{NLS_LANG}
connect()
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.
DBI
You need to install at least version 2.87 of CGI.pm to work under mod_perl 2.0, as earlier CGI.pm versions aren't mod_perl 2.0 aware.
This error is reported when some undefined Apache error happens. The known cases are:
A bug in mod_deflate was triggering this error, when a response handler would flush the data that was flushed earlier: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259 It has been fixed in httpd-2.0.48.
Apache uses the sendfile syscall on platforms where it is available in order to speed sending of responses. Unfortunately, on some systems, Apache will detect the presence of sendfile at compile-time, even when it does not work properly. This happens most frequently when using network or other non-standard file-system.
The whole story and the solutions are documented at: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile
It doesn't strictly belong to this document, since it's talking about APR usages outside of mod_perl, so this may move to its own dedicated page, some time later.
Whenever using an APR:: package outside of mod_perl, you need to:
APR::
use APR;
in order to load the XS subroutines. For example:
% perl -MApache2 -MAPR -MAPR::UUID -le 'print APR::UUID->new->format'
Maintainer is the person(s) you should contact with updates, corrections and patches.
Stas Bekman
Only the major authors are listed above. For contributors see the Changes file.
To install mod_perl, copy and paste the appropriate command in to your terminal.
cpanm
cpanm mod_perl
CPAN shell
perl -MCPAN -e shell install mod_perl
For more information on module installation, please visit the detailed CPAN module installation guide.