In-depth analysis of whether PHP will continue to execute after the browser exits, in-depth analysis of continued execution_PHP tutorial

In-depth analysis of whether php will continue to execute after the browser exits, in-depth analysis of continued execution

Premise: What is mentioned here is the typical lnmp structure, nginx php-fpm mode

If I have a php program that executes very slowly, even sleep() in the code, and then when the browser connects to the service, a php-fpm process will be started, but at this time, if the browser is closed, So, will the php-fpm process on the server continue to run at this time?

Today we are going to solve this problem.

The simplest experiment

The easiest way is to do an experiment. Let’s write a program: use file_put_contents to write logs before and after sleep:

<&#63;php
file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX);
sleep(3);
file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);

The result of the actual operation is that when we close the client browser while the server is sleeping, 2222 will be written to the log.

So this means that after the browser is closed, the server-side php will still continue to run?

ignore_user_abort

Lao Wang and diogin reminded that this may be related to the ignore_user_abort function of PHP.

So I changed the code slightly to this:

<&#63;php
ignore_user_abort(false);
file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX);
sleep(3);
file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);

It is found that there is no software use. No matter what value ignore_user_abort is set to, it will continue to execute.

But here is a question: What is user_abort?

The document makes it very clear about abort in cli mode. When the php script is executed and the user terminates the script, abort will be triggered. The script then determines whether to continue execution based on ignore_user_abort.

But the official document does not clearly describe abort in cgi mode. It seems that even if the client disconnects, PHP in cgi mode will not receive abort.

Does ignore_user_abort have no effect in cgi mode?

Is it a heartbeat problem?

The first thing that comes to mind is a heartbeat problem? When we disconnect the browser client, it is equivalent to disconnecting the connection without closing the client. The server needs to wait for the TCP keepalive to arrive before detecting it.

Okay, you need to troubleshoot the keepalive problem in the browser settings first.

Abandon the browser and simply write a client program: After the program connects to the http service, it sends a header and sleeps for 1 second before actively closing the connection. However, this program does not have the keepalive header of http.

The procedure is as follows:

package main

import "net"
import "fmt"
import "time"

func main() {
  conn, _ := net.Dial("tcp", "192.168.33.10:10011")
  fmt.Fprintf(conn, "GET /index.php HTTP/1.0\r\n\r\n")
  time.Sleep(1 * time.Second)
  conn.Close()
  return
}

Server program:

<&#63;php
ignore_user_abort(false);
file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX);
sleep(3);
file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);

I found that it is still the same. PHP will continue to execute the entire script regardless of whether ignore_user_abort is set or not. It seems that ignore_user_abort still does not take effect.

How to trigger ignore_user_abort

How to trigger ignore_user_abort? How does the server know that this socket cannot be used? Lao Wang and Diogin asked whether the server needs to actively interact with the socket to determine whether the socket can be used?

In addition, we also found that PHP provides two methods, connection_status and connection_aborted, both of which can detect the current connection status. So our logging line of code can be changed to:

file_put_contents('/tmp/test.log', '1 connection status: ' 
. connection_status() 
. "abort:" 
. connection_aborted() 
. PHP_EOL, FILE_APPEND | LOCK_EX);

According to the manual connection processing display, we can print out the current connection status.

The following is missing a program that interacts with the socket. We use echo, and remember to bring flush later to eliminate the influence of flush.

The program will be changed to

<&#63;php
ignore_user_abort(true);
file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX);

sleep(3);

for($i = 0; $i < 10; $i++) {
    echo "22222";
    flush();
    sleep(1);
    file_put_contents('/tmp/test.log', '2 connection status: ' . connection_status() . "abort:" . connection_aborted(). PHP_EOL, FILE_APPEND | LOCK_EX);

}

Very good, execute the client we wrote earlier. Observation log:

1 connection status: 0abort:0
2 connection status: 0abort:0
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1
2 connection status: 1abort:1

Finally made abort. The log also shows that the abort status for the next few times is 1.

But there is something strange here, why is the status of the first 2 connection status still 0 (NORMAL).

RST

We use wireshark to capture packets to see the entire interaction process between the client and the server

This whole process only sends 14 packets. Let’s see that when the server sends 22222 for the first time, the client returns RST. There will be no subsequent package requests.

So I understand, the approximate interaction process between the client and the server is:

When the server sends 2222 for the first time in the loop, the client has disconnected and returns an RST, but this sending process is considered a successful request. Until the second time the server wants to perform a write operation on this socket again, this socket will not perform network transmission, and directly returns that the connection status is abort. So the above situation occurred. The first time 222 was the status was 0, and the abort appeared only the second time.

strace for verification

We can also use strace php -S XXX to verify

The strace log of the entire process is as follows:

close(5)                = 0
lstat("/tmp/test.log", {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0
open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0
lseek(5, 0, SEEK_CUR)          = 0
lseek(5, 0, SEEK_CUR)          = 0
flock(5, LOCK_EX)            = 0
write(5, "1 connection status: 0abort:0\n", 30) = 30
close(5)                = 0
sendto(4, "HTTP/1.0 200 OK\r\nConnection: clo"..., 89, 0, NULL, 0) = 89
sendto(4, "111111111", 9, 0, NULL, 0)  = 9
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({3, 0}, 0x7fff60a40290)    = 0
sendto(4, "22222", 5, 0, NULL, 0)    = 5
open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=49873681, ...}) = 0
lseek(5, 0, SEEK_CUR)          = 0
lseek(5, 0, SEEK_CUR)          = 0
flock(5, LOCK_EX)            = 0
write(5, "2 connection status: 0abort:0\n", 30) = 30
close(5)                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7fff60a40290)    = 0
sendto(4, "22222", 5, 0, NULL, 0)    = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} ---
open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0
lseek(5, 0, SEEK_CUR)          = 0
lseek(5, 0, SEEK_CUR)          = 0
flock(5, LOCK_EX)            = 0
write(5, "2 connection status: 1abort:1\n", 30) = 30
close(5)                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7fff60a40290)    = 0
open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=49873741, ...}) = 0
lseek(5, 0, SEEK_CUR)          = 0
lseek(5, 0, SEEK_CUR)          = 0
flock(5, LOCK_EX)            = 0
write(5, "2 connection status: 1abort:1\n", 30) = 30
close(5) 
。。。我们照中看status从0到1转变的地方。

...
sendto(4, "22222", 5, 0, NULL, 0)    = 5
...
write(5, "2 connection status: 0abort:0\n", 30) = 30
close(5)                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7fff60a40290)    = 0
sendto(4, "22222", 5, 0, NULL, 0)    = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} ---
open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0
lseek(5, 0, SEEK_CUR)          = 0
lseek(5, 0, SEEK_CUR)          = 0
flock(5, LOCK_EX)            = 0
write(5, "2 connection status: 1abort:1\n", 30) = 30
close(5) 

Broken pipe was displayed when 2222 was sent to the socket for the second time. This is what the program tells us. This socket can no longer be used. By the way, the connection_status in php will be set to 1. Subsequent write operations will not be executed again.

Summary

Under normal circumstances, if the client is launched abnormally, the server program will continue to execute until it interacts with IO twice. The server finds that the client has disconnected. At this time, a user_abort will be triggered. If ignore_user_abort is not set, then the php-fpm program will be interrupted.

At this point, the problem is solved.

The above in-depth analysis of whether PHP will continue to execute after the browser is exited is all the content shared by the editor. I hope it can give you a reference, and I also hope that everyone will support Bangkejia.

http://www.bkjia.com/PHPjc/1127871.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1127871.htmlTechArticleIn-depth analysis of whether PHP will continue to execute after the browser exits, and in-depth analysis of the prerequisites for continued execution: What is mentioned here is typical lnmp structure, nginx php-fpm mode If I have a php program to execute...