FastCGI:aborted:select()失败

Question

我有运行Apache 2.2.4和PHP-FPM(FastCGI Process Manager)的VPS服务器(CentOS 6.5).每天2-3次我得到以下错误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

因此,apache并不总是停止,有时只有主进程停止并且工作进程仍然运行,这使我甚至无法重启apache,因为它仍在侦听端口80,但没有主进程和pid文件.

我看到有人提到要更新到mod_fastcgi 2.4.7(修补)修复了这个bug,但不幸的是RHEL/CentOS没有更新,所以这对我来说不是一个选项.(Apache PHP5-FPM连接由同行重置)

谷歌的答案还有线程,--idle-timeout在fastcgi.conf 中增加价值可以解决问题,但我没有看到原因.

请问这个问题的解决方案吗？

Answer 1

增加-idle-timeout(虽然^^前面只有一个破折号)确实是解决方案.这里给出了完整的解释,但我会试着解释一下:

PHP有自己的超时,设置max_execution_time.如果使用它运行mod_php,此设置告诉PHP在x秒后退出脚本.

下一步:FPM进程管理器有另一个,request_terminate_timeout在池配置中设置.这个限制/覆盖max_execution_time.

这就是纯PHP方面的部分.如果您使用的是PHP-FPM和FastCGI,PHP将在其自己的进程中启动.内部超时仍然适用.然而,FastCGI有自己的超时(PHP不需要它,但fastCGI现在应该如何拥有它自己的？),这可以确保网络服务器在某些CGI进程没有冻结时(或者只是工作了很长时间) ).

问题是:FastCGI只是杀死PHP和Apache之间的IO流,使PHP没有机会正常关闭.FastCGI已经收到的数据仍然移交给Apache - 如果它不完整,它会引发错误(你看到的不完整标题).除此之外,PHP进程保持在那里,在僵尸状态下运行,无法使用,因为IO流现在已经死了.您可能必须手动终止它们或等到PHP-FPM希望这样做(取决于进程管理器设置).您获得的其他错误由PHP生成,原因如下:管道已关闭,Apache在另一端"消失".

因此:确保FastCGIs超时(比至少一秒)更长request_terminate_timeout,并且这个超过您使用的最高值至少另一秒max_execution_time.

请注意,后者可以使用更改ini_set,因此请确保记住哪些值有效,哪些值无效 - 或者php_admin_value在FPM池配置中使用它们,因此无法在单个脚本中更改(请参阅文档).不是因为它是必要的(request_terminate_timeout只要它低于FastCGI超时就会正确终止PHP子max_execution_time进程),但是因为你的脚本可以在设置失败的情况下正确检测到超时,但是如果它们可以覆盖它们,那么它们会起作用(没有办法)request_terminate_timeout从PHP脚本内部读取).

您可以单独更改每个池的所有值:

• max_execution_time通过php_value/ php_admin_value在池配置内

• request_terminate_timeout 直接在池配置中

• -idle-timeoutApache配置中的FastCGI ,其中每个池都必须单独添加:

  FastCgiExternalServer /usr/lib/cgi-bin/external.php5.www -socket /var/run/php5-fpm/www.sock -pass-header Authorization -idle-timeout 310 -flush

  (路径当然可能不同,这只是我的配置引用,但我建议使用pass-header Authorization,虽然与此问题无关).