/ 
mod_perl-1.99_11
River stage three • 156 direct dependents • 184 total dependents
/ Troubleshooting

NAME

Troubleshooting mod_perl problems

Description

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

Building and Installation

Configuration and Startup

(28)No space left on device

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 -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:

% 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.

Segmentation Fault when Using DBI

Update DBI to at least version 1.31.

<Perl> directive missing closing '>'

See the Apache::PerlSections manpage.

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.

Error about not finding Apache.pm with CGI.pm

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.

20014:Error string not specified yet

This error is reported when some undefined Apache error happens. The known cases are:

when using mod_deflate

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.

(22)Invalid argument: core_output_filter: writing data to the network

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

Issues with APR Used Outside of mod_perl

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:

use APR;

in order to load the XS subroutines. For example:

% perl -MApache2 -MAPR -MAPR::UUID -le 'print APR::UUID->new->format'

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.