4

The php-fpm man page states the response to a USR2 signal is: "graceful reload of all workers + reload of fpm conf/binary". However, in testing I find that a reload actually kills workers processing requests. I was expecting requests to be allowed to finish before the processes were killed and re-spawned.

Is this broken, my expectation wrong, or test invalid?

My test setup:
Ubuntu 16.04 LXC container
install php7.0-fpm and nginx
php script to sleep and output countdown each second
send request to sleep for 30 seconds via curl
issue reload via systemctl

Test result:
request was killed immedietly upon reload

virullius
  • 1,058

1 Answers1

8

I just found my answer: configuration option process_control_timeout was set to a default value of 0 seconds. A terrible default in my opinion.

I set process_control_timeout to a value of 30s to allow child processes up to 30 seconds to complete and quit before being forcibly killed. However, this takes effect only on subsequent reloads as the first reload is required to put this change into effect.

virullius
  • 1,058
  • On which OS and php version did you get it working? I tried both 5.6 and 7.3 PHP-FPM and even with process_control_timeout=5 it kills the connection immediately. – Marki555 Jan 08 '20 at 15:31
  • 3
    I had to use 5s instead of 5 even the config file says the seconds are default unit for this option. – Marki555 Jan 08 '20 at 15:39
  • 1
    Worth noting that on top of the above, the following happens:
    1. PHP-FPM will not serve new requests until the reload finishes completely. All these new requests will, however, be queued by the fpm and executed immediately after the reload is complete. The result to the end user is that they see a browser loading spinner during that time.
    2. PHP-FPM will interrupt sleep()ing scripts as if the sleep() timeout was reached, making those scripts continue running. Potential issue if exact sleep() periods are relied upon.
    3. Above points were tested on php-fpm 5.5. Likely same on 7.x.
     – d-ph Jul 03 '20 at 17:18