FastCGI的：中止：选择（）失败 [英] FastCGI: aborted: select() failed

问题描述

我运行的Apache 2.2.4和PHP-FPM（FastCGI进程管理器）服务器VPS（CentOS的6.5）。
每日2-3次，我得到下面的 error_log中错误：

I have VPS server (CentOS 6.5) running Apache 2.2.4 and PHP-FPM (FastCGI Process Manager). 2-3 times a day I get following errors in error_log:

[error] [client 127.60.158.1] (4)Interrupted system call: FastCGI: comm with server "/usr/lib/cgi-bin/php5-fcgi" aborted: select() failed
[error] [client 127.60.158.1] FastCGI: incomplete headers (0 bytes) received from server "/usr/lib/cgi-bin/php5-fcgi"
[notice] caught SIGTERM, shutting down
[alert] (4)Interrupted system call: FastCGI: read() from pipe failed (0)
[alert] (4)Interrupted system call: FastCGI: the PM is shutting down, Apache seems to have disappeared - bye

而作为一个结果阿帕奇并不总是停，有时只主进程停止和工作进程仍在运行的prevents我甚至重新启动Apache，因为它仍然在80端口监听，但没有主进程和pid文件。

And as a result apache not always stops, sometimes only main process stops and worker processes still run which prevents me even to restart apache as it's still listening on port 80, but without main process and pid file.

我看到有人提更新到2.4.7的mod_fastcgi（补丁），它修复了BUG，但不幸的是RHEL / CentOS的不具有更新，所以这不是我的选择。 （阿帕奇PHP5-FPM被对方连接复位）

I saw somebody mention to update to mod_fastcgi 2.4.7 (patched) which fixes that bug, but unfortunately RHEL/CentOS doesn't have that updates, so that is not an option for me. (Apache PHP5-FPM connection reset by peer)

这是谷歌也有螺纹回答，增加的价值 - 在fastcgi.conf空闲超时就可以解决问题，但我看不到的原因。

Also there was thread on google answers that increasing value of --idle-timeout in fastcgi.conf can solve the issue, but I don't see the reason.

有什么解决，好吗？

推荐答案

增加 -idle超时（只是一个在前面，虽然^^破折号）确实是解决方案。在这个完整的给出的解释是<一个href=\"http://foaa.de/old-blog/2010/11/php-apache-and-fastcgi-a-com$p$phensive-overview/trackback/index.html#the-timeout-problem\"相对=nofollow>这里，但我会试着解释它：

Increasing -idle-timeout (just one dash in front though ^^) is indeed the solution. A complete explanation on this is given here, but I'll try to explain it:

PHP有它自己的超时，以的max_execution_time 设置。如果使用 mod_php的运行它，这个设置将告诉PHP退出x秒后的脚本工作。

PHP has it's own timeout, set in max_execution_time. If running it using mod_php, this setting tells PHP to quit working on a script after x seconds.

下一篇：FPM进程管理器具有一个又一个， request_terminate_timeout 设置在池配置。这其中限制/覆盖的max_execution_time 。

Next: the FPM process manager has another one, request_terminate_timeoutset in the pool configuration. This one limits / overrides max_execution_time.

这就是它的纯PHP端部分。如果你使用PHP-FPM和FastCGI，PHP是在自己的进程开始了。内部超时仍然适用。但是FastCGI的有它自己的超时值（这是不需要PHP，但应该如何FastCGI的PHP现在有自己的？），这可以确保如果一些CGI进程不会（或只是适用于很长一段时间的网络服务器不结冰）。

That's it for the pure PHP-side part. If you're using PHP-FPM and FastCGI, PHP is started in its own process. The internal timeouts still apply. FastCGI however has its own timeout (which isn't needed for PHP, but how should fastCGI now PHP has its own?), that makes sure the webserver doesn't freeze if some CGI process does (or just works for a very long time).

问题是：FastCGI的只是杀死PHP和Apache之间的IO流，让PHP没有机会正常关闭。这已经被FastCGI的接收的数据仍然交给Apache的 - 如果它是不完整的，它会产生一个错误（您看到不完整的标题中的一个）。除此之外，在PHP进程呆在那里，在一个僵尸般的状态下运行，不可用，因为有IO流是现在死了。您可能需要手动杀死他们，或者等到PHP-FPM可能会做（取决于进程管理器设置）。由PHP生成这个确切原因你得到其他错误：管道被关闭，Apache的另一端消失

The problem is: FastCGI just kills the IO stream between PHP and Apache, giving PHP no chance to properly shut down. Data that has already been received by FastCGI is still handed over to Apache - if it's incomplete, it'll raise an error (the one you see about incomplete headers). In addition to that, the PHP processes stay there, running in a zombie-like state, unusable because there IO stream is now dead. You may have to kill them manually or wait until PHP-FPM hopefully does (depending on process manager settings). The other errors you're getting are generated by PHP for this exact reason: Pipe was closed, Apache "disappeared" on the other end.

所以：确保FastCGIs超时比 request_terminate_timeout 较高（至少一秒钟），而这一次是由至少一秒钟比你使用的最高值高在的max_execution_time 。

So: Make sure FastCGIs timeout is higher (by at least one second) than request_terminate_timeout, and this one is higher by at least another second than the highest value you use in max_execution_time.

请注意的ini_set ，后者可以通过改变，所以一定要记住什么样的价值观做的工作，什么不 - 或者使用 php_admin_value 在你的FPM池配置，所以它不能单独脚本内改变（见的文档）。不是因为它是必要的（ request_terminate_timeout 将只要正确，因为它是比FastCGI的超时下终止PHP子女），而是因为你的脚本可以正确地检测超时，如果设置的max_execution_time 失败，同时他们也将asusme它的工作，如果他们可以覆盖它（有没有办法读 request_terminate_timeout ）。

Note that the latter can be changed using ini_set, so make sure to remember what values do work and what don't - or set it using php_admin_value in your FPM pool configuration, so it cannot be changed inside individual scripts (see the documentation). Not because it's necessary (request_terminate_timeout will terminate PHP children properly as long as it'S lower than the FastCGI timeout), but because your scripts can detect the timeout properly if setting max_execution_time fails, while they will asusme it worked if they can override it (there is no way to read request_terminate_timeout from inside PHP scripts).

您可以分别更改为每个池的所有值：

You can change all values for each pool separately:

• 的max_execution_time 通过 php_value / php_admin_value 池配置里面

request_terminate_timeout 直接在池中配置里面

FastCGIs -idle超时在Apache的配置，其中每个池都有单独反正加入：

FastCGIs -idle-timeout in the Apache config, where each pool has to be added separately anyway:

FastCgiExternalServer /usr/lib/cgi-bin/external.php5.www -socket /var/run/php5-fpm/www.sock -pass头授权-idle超时310 -flush

（路径当然也可以不同，这是刚刚从我的配置报价，但我建议你在通标头授权，虽然不是与此有关问题）。

(paths may be different of course, this is just a quote from my config, but I'd recommend the pass-header for Authorization, although not related to this problem).

这篇关于FastCGI的：中止：选择（）失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！