Thanks a lot. I was going crazy
To run a php file 180 seconds. You have to do:
(via panel) max_execution_time php_value to 180
(copy/edit where?) request_terminate_timeout directly inside the pool config to 183
(copy/edit) /opt/configs/apache/tpl/custom.domains.conf.tpl and then change '-idle-timeout 185'
Reload:
sh /script/fixweb; sh /script/restart-web -y
Recommended reading =>
http://stackoverflow.com/a/21595677/4717423Increasing -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 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.
Next: the FPM process manager has another one, request_terminate_timeoutset in the pool configuration. This one limits / overrides max_execution_time.
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).
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.
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.
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 via php_value/php_admin_value inside the pool config
request_terminate_timeout directly inside the pool config
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-header Authorization -idle-timeout 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).
Topic: php-fpm_event conf (Read 5470 times)
