Home>Article>Web Front-end> PHP implements daemon - backend
PHP implementation daemon can be implemented through thepcntl
andposix
extensions.
Things that need to be noted in programming are:
pcntl_fork()
andposix_setsid
Ignore or handle
SIGHUPsignal
or
pcntl_signal()Ignore the
SIGCHLDsignal to prevent the child process from becoming a Zombie process
to prevent inheritance of file permissions The resulting permission impact function
of the running process to
/dev/nullor other streams
Prevent operation error paths
In a multi-tasking computer operating system, a daemon (English: daemon, /ˈdiːmən/ or /ˈdeɪmən/) is a computer program that executes in the background. Such programs will be initialized as processes. The names of daemon programs usually end with the letter "d": for example, syslogd refers to the daemon that manages system logs.Advanced Programming in UNIX Environment (Second Edition) (hereinafter referred to as APUE) There is a cloud in Chapter 13:Usually, the daemon process does not have any existing parent process (that is, PPID=1), and is directly under init in the UNIX system process hierarchy. A daemon program usually makes itself a daemon by running fork on a child process, and then terminating its parent process immediately so that the child process can run under init. This method is often called "shelling."
The daemon process also becomes the elf process (daemon) is A process with a long life cycle. They are often started when the system boots and terminate only when the system is shut down. Because they don't have a controlling terminal, they are said to run in the background.It is noted here that daemon has the following characteristics:
ps -axor
ps -ef, where
-xmeans it will be listed There is no process controlling the terminal.
pcntlextension in PHP implements the
pcntl_fork()function, which is used to fork a new process in PHP.
Session,
Process Group.
&) will also be killed after the terminal is closed, that is, the
SIGHUP issued when the control terminal is disconnected is not handled properly.signal, and the default behavior of
SIGHUPsignal for a process is to exit the process.
setsidAfter the system call, the current process will create a new process group. If the terminal is not opened in the current process, then there will be no control terminal for this process group. There will be no problem of killing the process by closing the terminal.
posixextension in PHP implements the
posix_setsid()function, which is used to set a new process group in PHP.
First of all, thesetsid
system call cannot be called by the process group leader and will return -1.
The sample code for the second fork operation is as follows:
$pid1 = pcntl_fork(); if ($pid1 > 0) { exit(0); } else if ($pid1 < 0) { exit("Failed to fork 1\n"); } if (-1 == posix_setsid()) { exit("Failed to setsid\n"); } $pid2 = pcntl_fork(); if ($pid2 > 0) { exit(0); } else if ($pid2 < 0) { exit("Failed to fork 2\n"); }
Assume that we execute the application in the terminal, the process is a, and the first fork will generate a child process b. If fork succeeds, parent process a exits. b As an orphan process, it is hosted by the init process.
At this time, process b is in process group a, and process b callsposix_setsid
to request the generation of a new process group. After the call is successful, the current process group becomes b.
At this time, process b has actually separated from any control terminal, routine:
0) { exit(0); } else if ($pidA < 0) { exit(1); } cli_set_process_title('process_b'); if (-1 === posix_setsid()) { exit(2); } while(true) { sleep(1); }
After executing the program:
➜ ~ php56 2fork1.php ➜ ~ ps ax | grep -v grep | grep -E 'process_|PID' PID TTY STAT TIME COMMAND 28203 ? Ss 0:00 process_b
Judging from the results of ps, the TTY of process_b has become?
, that is, there is no corresponding control terminal.
When the code reaches this point, it seems that the function has been completed. process_b has not been killed after closing the terminal, but why is there a second fork operation?
An answer on StackOverflow is well written:
The second fork(2) is there to ensure that the new process is not a session leader, so it won't be able to (accidentally) allocate a controlling terminal, since daemons are not supposed to ever have a controlling terminal.
This is to prevent the actual working process from actively associating or accidentally associating with the controlling terminal, again The new process generated after fork cannot apply for an associated control terminal because it is not the leader of the process group.
To sum up, the function of secondary fork and setsid is to generate a new process group and prevent the working process from being associated with the control terminal.
The default action of a process receiving theSIGHUP
signal is to end the process.
AndSIGHUP
will be issued under the following circumstances:
Since the actual working process is not in the foreground process group, and the leader of the process group has exited and does not control the terminal, of course there will be no processing under normal circumstances. Problem, however, in order to prevent the process from exiting due to the accidental receipt ofSIGHUP
, and in order to follow the conventions of daemon programming, this signal should still be processed.
Simply speaking, the child process exits before the parent process, and the parent process does not call thewait
system call Processed, the process becomes a Zombie process.
When the child process exits before the parent process, it will send theSIGCHLD
signal to the parent process. If the parent process does not handle it, the child process will also become a Zombie process.
Zombie processes will occupy the number of processes that can be forked. Too many zombie processes will result in the inability to fork new processes.
In addition, in the Linux system, a process whose ppid is the init process will be recycled and managed by the init process after it becomes a Zombie.
From the characteristics of the Zombie process, for multi-process daemons, this problem can be solved in two ways:
SIGCHLD
SignalNo need to say more about the parent process' signal processing, just register the signal processing callback function and call the recycling method.
For the child process to be taken over by init, you can use the method of fork twice, so that the child process a from the first fork can then fork out the actual working process b, and let a exit first, so that b becomes Orphan process so that it can be hosted by the init process.
umask will be inherited from the parent process, affecting the permissions to create files.
The PHP manual mentions:
umask() sets PHP's umask to mask & 0777 and returns the original umask. When PHP is used as a server module, the umask is restored after each request.
If the umask of the parent process is not set properly, unexpected effects will occur when performing some file operations:
➜ ~ cat test_umask.phpSo, in order To ensure that files can be operated according to the expected permissions every time, the umask value needs to be set to 0.
Redirect 0/1/2
The 0/1/2 here refer to
STDIN/STDOUT/STDERR
respectively, that is, standard input/output/error three A flow.Sample
First let’s look at a sample:
0) { exit(0); } else if ($pid1 < 0) { exit("Failed to fork 1\n"); } if (-1 == posix_setsid()) { exit("Failed to setsid\n"); } $pid2 = pcntl_fork(); if ($pid2 > 0) { exit(0); } else if ($pid2 < 0) { exit("Failed to fork 2\n"); } umask(0); declare(ticks = 1); pcntl_signal(SIGHUP, SIG_IGN); echo getmypid() . "\n"; while(true) { echo time() . "\n"; sleep(10); }The above code has almost completed all aspects mentioned at the beginning of the article, the only The difference is that the standard stream is not processed. The program can also be run in the background through the
php not_redirect_std_stream_daemon.php
directive.在
sleep
的间隙,关闭终端,会发现进程退出。通过
strace
观察系统调用的情况:➜ ~ strace -p 6723 Process 6723 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>) = 0 write(1, "1503417004\n", 11) = 11 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({10, 0}, 0x7fff71a30ec0) = 0 write(1, "1503417014\n", 11) = -1 EIO (Input/output error) close(2) = 0 close(1) = 0 munmap(0x7f35abf59000, 4096) = 0 close(0) = 0发现发生了 EIO 错误,导致进程退出。
原因很简单,即我们编写的 daemon 程序使用了当时启动时终端提供的标准流,当终端关闭时,标准流变得不可读不可写,一旦尝试读写,会导致进程退出。
在信海龙的博文《一个echo引起的进程崩溃》中也提到过类似的问题。
解决方案
APUE 样例
APUE 13.3中提到过一条编程规则(第6条):
某些守护进程打开
/dev/null
时期具有文件描述符0、1和2,这样,任何一个视图读标准输入、写标准输出或者标准错误的库例程都不会产生任何效果。因为守护进程并不与终端设备相关联,所以不能在终端设备上显示器输出,也无从从交互式用户那里接受输入。及时守护进程是从交互式会话启动的,但因为守护进程是在后台运行的,所以登录会话的终止并不影响守护进程。如果其他用户在同一终端设备上登录,我们也不会在该终端上见到守护进程的输出,用户也不可期望他们在终端上的输入会由守护进程读取。简单来说:
例程中使用:
for (i = 0; i < rl.rlim_max; i++) close(i); fd0 = open("/dev/null", O_RDWR); fd1 = dup(0); fd2 = dup(0);
实现了这一个功能。dup()
(参考手册)系统调用会复制输入参数中的文件描述符,并复制到最小的未分配文件描述符上。所以上述例程可以理解为:
关闭所有可以打开的文件描述符,包括标准输入输出错误; 打开/dev/null并赋值给变量fd0,因为标准输入已经关闭了,所以/dev/null会绑定到0,即标准输入; 因为最小未分配文件描述符为1,复制文件描述符0到文件描述符1,即标准输出也绑定到/dev/null; 因为最小未分配文件描述符为2,复制文件描述符0到文件描述符2,即标准错误也绑定到/dev/null;
Workerman 中的 Worker.php 中的resetStd()
方法实现了类似的操作。
/** * Redirect standard input and output. * * @throws Exception */ public static function resetStd() { if (!self::$daemonize) { return; } global $STDOUT, $STDERR; $handle = fopen(self::$stdoutFile, "a"); if ($handle) { unset($handle); @fclose(STDOUT); @fclose(STDERR); $STDOUT = fopen(self::$stdoutFile, "a"); $STDERR = fopen(self::$stdoutFile, "a"); } else { throw new Exception('can not open stdoutFile ' . self::$stdoutFile); } }
Workerman 中如此实现,结合博文,可能与 PHP 的 GC 机制有关,对于 fd 0 1 2来说,PHP 会维持对这三个资源的引用计数,在直接 fclose 之后,会使得这几个 fd 对应的资源类型的变量引用计数为0,导致触发回收。所需要做的就是将这些变量变为全局变量,保证引用的存在。
推荐教程:《php教程》
The above is the detailed content of PHP implements daemon - backend. For more information, please follow other related articles on the PHP Chinese website!