tags:

views:

256

answers:

1

We've just ported a fairly large codebase from an ancient Perl 5.005.03 CGI environment to mod_perl 2, and now that it's undergoing a public beta there are a few, possibly related, issues we're encountering from time to time. These build up until we have to restart the server.

All of our code compiles under use strict, but has been previously called as a compiled, run and discarded CGI script. Problems we've encountered so far: setting $| or calling STDOUT->autoflush(1); using old-style global filehandles (open(ERRORFILE, $errorfile) rather than open(my $fh_error, $errorfile)). Also calling system() - shortly after we started the public beta, we spotted e.g. /bin/tail or /usr/sbin/sendmail listening on ports 80 and 443, which stopped the server from being restarted. I've since rewritten that code to use pure-Perl methods, and we no longer have that problem.

Two issues remain. The first one is that the logs are full of mod_perl complaining about constants having been redefined, e.g.

Constant subroutine ModPerl::ROOT::ModPerl::PerlRun::usr_local_..._cgi_forgotpassword::O_CREAT redefined at /usr/lib/perl5/ModPerl/Util.pm line 69.

Also, occasionally seemingly core variables will get trashed. One of our core in-house modules logs information about the PID and name of the script, and produced information like this:

20090202-233948-32154:Started script /usr/local/.../cgi/account/renewalcalendar
20090202-233948-32154:Ended script /usr/sbin/apache2

At other times the process ID will end up as undef. This is rare and intermittent.

Secondly, and also intermittently, we will occasionally see garbage collection not kick in. (Perhaps an issue of weak references? But nearly all of the time everything works fine.) The most immediate symptom of this is database handles opened that are never closed, but when I delve deeper into the issue, it becomes apparent that there's a DBI object stored in a standard Perl hash object, and that object's DESTROY method is (rarely and intermittently) not called.

We're running Debian 5.0 (Lenny), Perl 5.10.0, Apache 2.29, mod_perl 2.0.4, openSSL 0.9.8g. I can provide more information if necessary, but I think that's the basics.

The salient parts of the apache config, being _/etc/apache2/sites-enabled/sitename_, are (some bits redacted for confidentiality reasons):

<VirtualHost ...:443>
<Directory />
    Options SymLinksIfOwnerMatch
    AllowOverride None
</Directory>
<Directory /usr/local/.../cgi>
    SetHandler perl-script
    PerlResponseHandler ModPerl::PerlRun
    PerlOptions +ParseHeaders
    Options +ExecCGI
</Directory>
</VirtualHost>

There's some SSL, rewrites and redirection stuff going on there, but that's the important stuff.

Does this sound familiar to anyone? Alternatively, can anyone recommend any way of debugging the problem further?

+2  A: 

For your memory problem: you need to call weaken (from standard module Scalar::Util)

Leon Timmermans
Thanks; I'll do some more reading on weak references. But why would this only occur occasionally?
Sam Kington