Solution about php-fpm reload canceling the request being processed

start

In testing, it was found that php-fpm reload will force kill the request being processed. I checked online and found that other people also have this problem and reported it to the official: https://bugs.php.net/bug.php?id=75440 and https://bugs.php.net/bug.php?id =60961 , the post is from 2017 and 2012, and it has not been resolved yet.

The official help manual also says that reload is graceful , ahaha, don't believe it too much:

 man php-fpm
...
SIGINT,SIGTERM
    immediate termination
    SIGQUIT 
graceful stop
    SIGUSR1 
re-open log file
SIGUSR2
    graceful reload of all workers + reload of fpm conf/binary
...

Introduction to the reload process

php-fpm is master worker works.

The php-fpm master process realizes its own service by accepting the SIGUSR2 signal sent by the user reload :

 kill -USR2 <pid>

The master process (master process) receives the reload signal, and will send the SIGGUIT signal to all child processes, and register the timer time at the same time. The value of timeout is fpm_global_config.process_control_timeout . If the child process has not ended within the specified time, the child process will be killed. For example, if the timeout value is set to 1 second, if it does not end within 1 second, it will directly send the SIGKILL signal to the child process to forcibly kill it.

Finally, after the master waits for all child processes to end, restarts a process according to the previously saved startup parameters, and inherits the socket file descriptor of the parent process.

slow down

Note that this is only a mitigation solution, and there is still no guarantee that requests will not be lost. process_control_timeout这个配置选项， php-fpm.conf (我的/usr/local/etc/php-fpm.conf )中， 0 ， The child process will be killed immediately, here I changed it to 60s for testing:

 ; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 60s

As a result of the test, the request being processed can be returned normally as long as the request is completed within this time.

This is not a 100% solution because the master process has to wait for all child processes to end before re-creating the worker process, and while process_control_timeout is waiting, the worker process does not accept the request, so during this time the new If the request cannot come in, these new requests will be queued by fpm. If nginx times out, it will report 502 to the user. To be safe, the value of nginx's timeout time should be twice that of process_control_timeout .

Although a 502 may be reported, this is much more acceptable than killing the request being processed.

Summarize

Despite the setting process_control_timeout , on top of the above, PHP-FPM will not serve new requests until the reload is complete. However, all these new requests will be queued by fpm and executed as soon as the reload is complete. The result for the end user is that during this time they see the browser display Loading. Another point is that the set timeout does not guarantee that the request will be processed within this time, and the programmer still needs to ensure that the running time of his script is within a reasonable range.