php - FastCGI: aborted: select() failed -

i have vps server (centos 6.5) running apache 2.2.4 , php-fpm (fastcgi process manager). 2-3 times day following errors in error_log:

[error] [client 127.60.158.1] (4)interrupted system call: fastcgi: comm server "/usr/lib/cgi-bin/php5-fcgi" aborted: select() failed [error] [client 127.60.158.1] fastcgi: incomplete headers (0 bytes) received server "/usr/lib/cgi-bin/php5-fcgi" [notice] caught sigterm, shutting down [alert] (4)interrupted system call: fastcgi: read() pipe failed (0) [alert] (4)interrupted system call: fastcgi: pm shutting down, apache seems have disappeared - bye 

and result apache not stops, main process stops , worker processes still run prevents me restart apache it's still listening on port 80, without main process , pid file.

i saw mention update mod_fastcgi 2.4.7 (patched) fixes bug, unfortunately rhel/centos doesn't have updates, not option me. (apache php5-fpm connection reset peer)

also there thread on google answers increasing value of --idle-timeout in fastcgi.conf can solve issue, don't see reason.

any solutions problem, please?

increasing -idle-timeout (just 1 dash in front though ^^) indeed solution. complete explanation on given here, i'll try explain it:

php has it's own timeout, set in max_execution_time. if running using mod_php, setting tells php quit working on script after x seconds.

next: fpm process manager has one, request_terminate_timeoutset in pool configuration. 1 limits / overrides max_execution_time.

that's pure php-side part. if you're using php-fpm , fastcgi, php started in own process. internal timeouts still apply. fastcgi has own timeout (which isn't needed php, how should fastcgi php has own?), makes sure webserver doesn't freeze if cgi process (or works long time).

the problem is: fastcgi kills io stream between php , apache, giving php no chance shut down. data has been received fastcgi still handed on apache - if it's incomplete, it'll raise error (the 1 see incomplete headers). in addition that, php processes stay there, running in zombie-like state, unusable because there io stream dead. may have kill them manually or wait until php-fpm (depending on process manager settings). other errors you're getting generated php exact reason: pipe closed, apache "disappeared" on other end.

so: make sure fastcgis timeout higher (by @ least 1 second) request_terminate_timeout, , 1 higher @ least second highest value use in max_execution_time.

note latter can changed using ini_set, make sure remember values work , don't - or set using php_admin_value in fpm pool configuration, cannot changed inside individual scripts (see documentation). not because it's necessary (request_terminate_timeout terminate php children long it's lower fastcgi timeout), because scripts can detect timeout if setting max_execution_time fails, while asusme worked if can override (there no way read request_terminate_timeout inside php scripts).

you can change values each pool separately:

• max_execution_time via php_value/php_admin_value inside pool config

• request_terminate_timeout directly inside pool config

• fastcgis -idle-timeout in apache config, each pool has added separately anyway:

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

  (paths may different of course, quote config, i'd recommend pass-header authorization, although not related problem).