如何避免在 Apache 1.3 下运行的 Perl CGI 脚本中出现僵尸？

Question

各种 Perl 脚本（服务器端包含）正在调用网站上具有许多功能的 Perl 模块。 编辑： 这些脚本使用 use lib 来引用文件夹中的库。 在繁忙期间，脚本（而不是库）会变成僵尸并导致服务器过载。

服务器列表：

319 ?        Z      0:00 [scriptname1.pl] <defunct>    
320 ?        Z      0:00 [scriptname2.pl] <defunct>    
321 ?        Z      0:00 [scriptname3.pl] <defunct>

我每个都有数百个实例。

编辑： 除了 SSI 指令之外，我们没有使用 fork、system 或 exec

<!--#exec cgi="/cgi-bin/scriptname.pl"-->

据我所知，在这种情况下，httpd 本身将是进程的所有者。 MaxRequestPerChild 设置为 0，这不应该让父进程在子进程完成之前死亡。

到目前为止，我们认为暂时挂起一些脚本可以帮助服务器处理已失效的进程并防止其崩溃，但毫无疑问僵尸进程仍在形成。 显然，gbacon 的理论似乎最接近事实，即服务器无法应对负载。

什么可能导致 httpd 放弃这些进程？ 是否有任何最佳实践可以防止这些情况发生？

谢谢

回答： 重点是罗布。 正如他所说，生成 SSI 的 CGI 脚本不会处理这些 SSI。在 Apache 1.3 请求周期中，SSI 的评估发生在 CGI 运行之前。 Apache 2.0 及更高版本已修复此问题，以便 CGI 可以生成 SSI 命令。

由于我们在 Apache 1.3 上运行，因此对于每个页面视图，SSI 都会变成失效进程。尽管服务器试图清除它们，但由于正在运行的任务太忙而无法成功。结果，服务器摔倒并变得无响应。 作为短期解决方案，我们审查了所有 SSI，并将一些进程移至客户端，以释放服务器资源并给其时间进行清理。 后来我们升级到Apache 2.2。

Answer 1

比最佳实践更多的创可贴，但有时您可以根据

$SIG{CHLD} = "IGNORE";

perlipc 文档

在大多数 Unix 平台上，CHLD（有时也称为 CLD）信号对于 'IGNORE' 值具有特殊行为>。在此类平台上将 $SIG{CHLD} 设置为 'IGNORE' 具有在父进程未能 wait() 其子进程（即，子进程会自动收获）。在此类平台上，调用将 $SIG{CHLD} 设置为 'IGNORE' 的 wait() 通常会返回 -1。




如果您关心子进程的退出状态，则需要通过调用 等待 或 waitpid 。尽管名字令人毛骨悚然，僵尸只是一个已经退出但尚未获得状态的子进程。

如果您的 Perl 程序本身是成为僵尸的子进程，则意味着它们的父进程（那些分叉并忘记您的代码的进程）需要自行清理。进程无法阻止自己变成僵尸。

Answer 2

我刚刚看到您的评论，您正在运行 Apache 1.3，这可能与您的问题有关。

SSI 可以运行 CGI。但生成 SSI 的 CGI 脚本不会处理这些 SSI。在 Apache 1.3 请求周期中，SSI 的评估发生在 CGI 运行之前。 Apache 2.0 及更高版本已修复此问题，以便 CGI 可以生成 SSI 命令。

正如我上面所建议的，尝试单独运行脚本并查看输出。他们会生成 SSI 吗？

编辑：您是否尝试过启动一个简单的 Perl CGI 脚本来简单地打印出 Hello World 类型的 HTTP 响应？

然后，如果这有效，请添加一个简单的 SSI 指令，例如

<!--#printenv -->

并看看会发生什么。

编辑2：刚刚意识到可能发生了什么。当子进程退出且未被回收时，就会出现僵尸进程。这些进程徘徊并慢慢耗尽进程表中的资源。没有父进程的进程是孤立进程。

您是否在 Perl 脚本中分叉进程？如果是这样，您是否向父级添加了 waitpid() 调用？

您在脚本中是否也得到了正确的退出？

CORE::exit(0);

Answer 3

由于您自己拥有所有位，因此我建议从命令行一次运行一个单独的脚本，看看是否可以发现挂起的脚本。

ps 列表是否显示某个特定脚本正在运行的实例数量过多？

您是否使用 mod_perl 运行 CGI？

编辑：刚刚看到您对 SSI 的评论。不要忘记 SSI 指令本身可以运行 Perl 脚本。看看 CGI 正在尝试运行什么？

它们是否依赖于另一台服务器或服务？