Nous venons de porter un code assez grand d'un ancien environnement CGI Perl 5.005.03 vers mod_perl 2, et maintenant qu'il subit une bêta publique, il y a quelques problèmes, éventuellement liés, que nous rencontrons. re rencontre de temps en temps. Ceux-ci s'accumulent jusqu'à ce que nous devions redémarrer le serveur.mod_perl 2 corruption de variables et de processus
Tout notre code compile sous l'utilisation stricte, mais a été précédemment appelé comme un script CGI compilé, exécuté et mis au rebut. Problèmes que nous avons rencontrés jusqu'à présent: définir $| ou appeler STDOUT->autoflush(1); en utilisant des handles de fichiers globaux (open(ERRORFILE, $errorfile) plutôt que open(my $fh_error, $errorfile)). Appelez également system() - peu de temps après avoir lancé la version bêta publique, nous avons repéré par exemple./bin/tail ou/usr/sbin/sendmail écoutant sur les ports 80 et 443, ce qui a empêché le redémarrage du serveur. Depuis, j'ai réécrit ce code pour utiliser des méthodes pure-Perl, et nous n'avons plus ce problème.
Deux problèmes subsistent. Le premier est que les journaux sont pleins de mod_perl se plaindre de constantes ayant été redéfinies, par exemple.
Constant subroutine ModPerl::ROOT::ModPerl::PerlRun::usr_local_..._cgi_forgotpassword::O_CREAT redefined at /usr/lib/perl5/ModPerl/Util.pm line 69.
De même, les variables de base semblent parfois être supprimées. L'un de nos principaux modules internes enregistre des informations sur le PID et le nom du script et des informations produit comme celui-ci:
20090202-233948-32154:Started script /usr/local/.../cgi/account/renewalcalendar
20090202-233948-32154:Ended script /usr/sbin/apache2
D'autres fois, l'ID de processus finira comme undef. Ceci est rare et intermittent. Deuxièmement, et aussi par intermittence, nous verrons occasionnellement la collecte des ordures pas kick dans (peut-être un problème de références faibles? Mais presque tout le temps tout fonctionne bien.) Le symptôme le plus immédiat de cela est les poignées de base de données ouvertes que ne sont jamais fermés, mais quand je approfondis le problème, il devient évident qu'il y a un objet DBI stocké dans un objet de hachage Perl standard, et que la méthode DESTROY de cet objet n'est pas (rarement et par intermittence) appelée.
Nous utilisons Debian 5.0 (Lenny), Perl 5.10.0, Apache 2.29, mod_perl 2.0.4, openSSL 0.9.8g. Je peux fournir plus d'informations si nécessaire, mais je pense que c'est la base.
Les parties saillantes de la configuration apache, étant /etc/apache2/sites-enabled/* nomdusite *, sont (quelques bits expurgés pour des raisons de confidentialité):
<VirtualHost ...:443>
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
<Directory /usr/local/.../cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
Options +ExecCGI
</Directory>
</VirtualHost>
Il y a un certain SSL, réécritures et des trucs de redirection, mais c'est important.
Cela vous semble familier? Alternativement, quelqu'un peut-il recommander un moyen de déboguer le problème plus loin?
Il aurait été plus facile si vos ouvertes deux questions distinctes pour ce –
je vois votre point. Cependant, n'étant pas sûr de la façon dont tout cela était lié, j'ai préféré mettre tout en une question plutôt que d'omettre des informations potentiellement importantes ou des indices. Je vais essayer d'ajuster la question une fois que j'ai résolu le problème. –
Utilisez-vous un fichier de démarrage pour précharger les modules Perl? Si c'est le cas, vous devrez vous assurer qu'aucun d'entre eux n'ouvre des descripteurs de fichiers (descripteurs de base de données, sockets, descripteurs de fichiers, etc.) lors de la compilation (c'est-à-dire des blocs BEGIN). Si c'est le cas, alors vous aurez quelques problèmes majeurs qui n'apparaîtront pas en mode CGI. – mpeters