mod_perl 2 变量和进程损坏
我们刚刚将相当大的代码库从古老的 Perl 5.005.03 CGI 环境移植到 mod_perl 2，现在它正在进行公开测试，我们时不时会遇到一些可能相关的问题。 这些会一直累积到我们必须重新启动服务器为止。
我们所有的代码都在 use strict 下编译，但之前已被调用为已编译、运行和丢弃的 CGI 脚本。 到目前为止我们遇到的问题：使用旧式全局文件句柄设置 $| 或调用 STDOUT->autoflush(1); (open(ERRORFILE, $errorfile) 而不是 open(my $fh_error, $errorfile))。 还调用 system() - 在我们开始公开测试版后不久，我们发现 /bin/tail 或 /usr/sbin/sendmail 正在端口 80 和 443 上监听，这阻止了服务器重新启动。 我已经重写了该代码以使用纯 Perl 方法，并且我们不再遇到这个问题。
仍然存在两个问题。 第一个是日志中充满了 mod_perl 抱怨常量已被重新定义，例如
Constant subroutine ModPerl::ROOT::ModPerl::PerlRun::usr_local_..._cgi_forgotpassword::O_CREAT redefined at /usr/lib/perl5/ModPerl/Util.pm line 69.
另外，有时看似核心的变量会被丢弃。 我们的核心内部模块之一记录有关脚本的 PID 和名称的信息，并生成如下信息：
20090202-233948-32154:Started script /usr/local/.../cgi/account/renewalcalendar
20090202-233948-32154:Ended script /usr/sbin/apache2
在其他时候，进程 ID 将最终为 undef。 这种情况很少见，而且是间歇性的。
其次，也是间歇性的，我们偶尔会看到垃圾收集没有启动。（也许是弱引用的问题？但几乎所有时间一切都工作正常。）最直接的症状是打开的数据库句柄从未关闭，但是当我深入研究这个问题时，很明显有一个 DBI 对象存储在标准 Perl 哈希对象中，并且该对象的 DESTROY 方法（很少且间歇性地）没有被调用。
我们正在运行 Debian 5.0 (Lenny)、Perl 5.10.0、Apache 2.29、mod_perl 2.0.4、openSSL 0.9.8g。 如有必要，我可以提供更多信息，但我认为这就是基础知识。
apache 配置的显着部分是 /etc/apache2/sites-enabled/*sitename*（出于保密原因对一些内容进行了编辑）：
<VirtualHost ...:443>
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
<Directory /usr/local/.../cgi>
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
PerlOptions +ParseHeaders
Options +ExecCGI
</Directory>
</VirtualHost>
那里有一些 SSL、重写和重定向的内容，但这才是重要的事情。
这听起来很熟悉吗？ 或者，有人可以推荐任何进一步调试问题的方法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于您的内存问题：您需要调用weak（来自标准模块 Scalar::Util)
For your memory problem: you need to call weaken (from standard module Scalar::Util)