本文目录一览：
如何用php-fpm 执行php程序
第一步：确定php-fpm配置文件的路径，执行：
ps -aux | grep php-fpm
图中，我的是在 /soft/php7/etc/ 目录，在这个目录下有个php-fpm.d目录，打开这个目录后，找到文件，修改该文件里：
user = www
group = www
php-fpm的工作机制
概括来说，fpm 的实现就是创建一个 master 进程，在 master 进程中创建并监听 socket，然后 fork 出多个子进程，这些子进程各自 accept 请求，子进程的处理非常简单，它在启动后阻塞在 accept 上，有请求到达后开始读取请求数据，读取完成后开始处理然后再返回，在这期间是不会接收其它请求的，也就是说 fpm 的子进程同时只能响应一个请求，只有把这个请求处理完成后才会 accept 下一个请求，这一点与 nginx 的事件驱动有很大的区别，nginx 的子进程通过 epoll 管理套接字，如果一个请求数据还未发送完成则会处理下一个请求，即一个进程会同时连接多个请求，它是非阻塞的模型，只处理活跃的套接字。
fpm 的 master 进程与 worker 进程之间不会直接进行通信，master 通过共享内存获取 worker 进程的信息，比如 worker 进程当前状态、已处理请求数等，当 master 进程要杀掉一个 worker 进程时则通过发送信号的方式通知 worker 进程。
fpm 可以同时监听多个端口，每个端口对应一个 worker pool，而每个 pool 下对应多个 worker 进程，类似 nginx 中 server 概念。
在 php-fpm.conf 中通过[pool name]声明一个 worker pool：
启动 fpm 后查看进程：
具体实现上 worker pool 通过fpm_worker_pool_s这个结构表示，多个 worker pool 组成一个单链表
接下来看下 fpm 的启动流程，从main()函数开始：
fpm_init()主要有以下几个关键操作：
(1) fpm_conf_init_main():
解析 php-fpm.conf 配置文件，分配 worker pool 内存结构并保存到全局变量中：fpm_worker_all_pools，各 worker pool 配置解析到fpm_worker_pool_s-config中。
(2)fpm_scoreboard_init_main():
分配用于记录 worker 进程运行信息的共享内存，按照 worker pool 的最大 worker 进程数分配，每个 worker pool 分配一个fpm_scoreboard_s结构，pool 下对应的每个 worker 进程分配一个fpm_scoreboard_proc_s结构。
(3)fpm_signals_init_main():
这里会通过socketpair()创建一个管道，这个管道并不是用于 master 与 worker 进程通信的，它只在 master 进程中使用，具体用途在稍后介绍 event 事件处理时再作说明。另外设置 master 的信号处理 handler，当 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 这些信号时将调用sig_handler()处理：
(4)fpm_sockets_init_main()
创建每个 worker pool 的 socket 套接字。
(5)fpm_event_init_main():
启动 master 的事件管理，fpm 实现了一个事件管理器用于管理 IO、定时事件，其中 IO 事件通过 kqueue、epoll、poll、select 等管理，定时事件就是定时器，一定时间后触发某个事件。
在fpm_init()初始化完成后接下来就是最关键的fpm_run()操作了，此环节将 fork 子进程，启动进程管理器，另外 master 进程将不会再返回，只有各 worker 进程会返回，也就是说fpm_run()之后的操作均是 worker 进程的。
在 fork 后 worker 进程返回了监听的套接字继续 main() 后面的处理，而 master 将永远阻塞在fpm_event_loop()，接下来分别介绍 master、worker 进程的后续操作。
fpm_run()执行后将 fork 出 worker 进程，worker 进程返回main()中继续向下执行，后面的流程就是 worker 进程不断 accept 请求，然后执行 PHP 脚本并返回。整体流程如下：
worker 进程一次请求的处理被划分为 5 个阶段：
worker 处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s-request_stage，master 进程正是通过这个标识判断 worker 进程是否空闲的。
接下来我们来看下 master 是如何管理 worker 进程的，首先介绍下三种不同的进程管理方式：
前面介绍到在fpm_run()中 master 进程将进入fpm_event_loop()：
这就是 master 整体的处理，其进程管理主要依赖注册的几个事件，接下来我们详细分析下这几个事件的功能。
(1)sp[1]管道可读事件：
在 fpm_init() 阶段 master 曾创建了一个全双工的管道：sp，然后在这里创建了一个 sp[0] 可读的事件，当 sp[0] 可读时将交由 fpm_got_signal() 处理，向 sp[1] 写数据时 sp[0] 才会可读，那么什么时机会向 sp[1] 写数据呢？前面已经提到了：当 master 收到注册的那几种信号时会写入 sp[1] 端，这个时候将触发 sp[0] 可读事件。
这个事件是 master 用于处理信号的，我们根据 master 注册的信号逐个看下不同用途：
具体处理逻辑在 fpm_got_signal() 函数中，这里不再罗列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
这是进程管理实现的主要事件，master 启动了一个定时器，每隔 1s 触发一次，主要用于 dynamic、ondemand 模式下的 worker 管理，master 会定时检查各 worker pool 的 worker 进程数，通过此定时器实现 worker 数量的控制，处理逻辑如下：
(3)fpm_pctl_heartbeat():
这个事件是用于限制 worker 处理单个请求最大耗时的，php-fpm.conf 中有一个request_terminate_timeout的配置项，如果 worker 处理一个请求的总时长超过了这个值那么 master 将会向此 worker 进程发送kill -TERM信号杀掉 worker 进程，此配置单位为秒，默认值为 0 表示关闭此机制，另外 fpm 打印的 slow log 也是在这里完成的。
除了上面这几个事件外还有一个没有提到，那就是 ondemand 模式下 master 监听的新请求到达的事件，因为 ondemand 模式下 fpm 启动时是不会预创建 worker 的，有请求时才会生成子进程，所以请求到达时需要通知 master 进程，这个事件是在fpm_children_create_initial()时注册的，事件处理函数为fpm_pctl_on_socket_accept()，具体逻辑这里不再展开，比较容易理解。
原文出处：
如何用supervisor守护php-fpm主进程以实现php-fpm的自动重启
1. 安装supervisor
supervisor本身是python实现的，而且是调研阶段，故先创建一个新的virtualenv环境，然后用pip安装好supervisor包。
至此，基本的调研环境搭建完毕。当然，php-fpm和PHP环境以及前端的Nginx是早就ready的。
2. 分析php-fpm.sh脚本
通常编译安装PHP后，php-fpm这个2进制的C程序也会被编译并安装好，典型路径在php_install_path/sbin/目录下。该
目录下还有个名为php-fpm.sh的脚本用于控制php-fpm进程的start/stop/restart/reload等动作。
./sbin/php-fpm.sh脚本中，”start”操作启动了php-fpm主进程，其余的操作都是通过向php-fpm master进程发signal实现的。
code class="hljs bash"## code segment in php-fpm.sh
case "$1" in
start)
echo -n "Starting php-fpm "
## 下面这行是关键命令
$php_fpm_BIN --daemonize $php_opts
if [ "$?" != 0 ] ; then
echo " failed"
exit 1
fi
wait_for_pid created $php_fpm_PID
if [ -n "$try" ] ; then
echo " failed"
exit 1
else
echo " done"
fi
;;/code
从上面是终端输入”./sbin/php-fpm.sh
start”时，实际执行的代码，可以看到，php-fpm进程的启动参数是–daemonize
$php_opts，而$php_opts的值为”–fpm-config $php_fpm_CONF –pid $php_fpm_PID”。
注意: php-fpm.sh启动php-fpm master进程时，传入了daemonize参数，表明php-fpm master process以守护（daemon）方式启动，而根据supervisor文档的说明，当用supervisor监护进程时，被监护进程不能是守护进程，这是由于守护进程通常会在fork完子进程后就让父进程”结束生命”，也即由supervisor创建的父进程退出，此时，supervisor无法再监护已退出进程创建出来的子进程。关于daemon process的行为，可以参考Linux Daemon Writing HOWTO一文来理解。
根据上面的分析，我们知道，只要supervisor启动php-fpm进程时，不传入daemonize参数即可。
3. 实现php-fpm主进程守护功能的supervisor配置文件
上面的分析已经告诉我们应该怎么解决问题了，下面直接上验证可用的配置文件。文件位于php-fpm.conf同级目录下（典型路径为php_install_path/etc/）。
code class="hljs bash"code class="hljs vhdl"
[inet_http_server] ; inet (TCP) server disabled by default
port=127.0.0.1:9015 ; (ip_address:port specifier, *:port for all iface)
[supervisord]
logfile=./var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=2 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=./var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
identifier=sup.php-fpm ; (supervisord identifier, default is 'supervisor')
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl= ; use an http:// url to specify an inet socket
[program:php-fpm]
command=bash -c "sleep 1 /home/slvher/tools/php/5.6.11/sbin/php-fpm --fpm-config /home/slvher/tools/php/5.6.11/etc/php-fpm.conf --pid /home/slvher/tools/php/5.6.11/var/run/php-fpm.pid" ; the program (relative uses PATH, can take args)
process_name=%(program_name)s ; process_name expr (default %(program_name)s)
autostart=true ; start at supervisord start (default: true)
autorestart=true ; whether/when to restart (default: unexpected)
startretries=5 ; max # of serial start failures (default 3)
exitcodes=0,2,70 ; 'expected' exit codes for process (default 0,2)
stopsignal=QUIT ; signal used to kill process (default TERM)
stopwaitsecs=2 ; max num secs to wait b4 SIGKILL (default 10)
/code/code
配置文件结构通过查看supervisor文档很容易就能掌握，有两个配置项需要特别注意：
1) command
它指定了supervisor要监控的进程的启动命令，可以看到，这里我们没有给php-fpm传入daemonize参数，其余参数只是展开了php-fpm.sh中的shell变量而已。
大家已经注意到，command也不是直接调起php-fpm，而是通过bash -c执行了两个命令，而第一个命令是sleep 1。这是由于php-fpm在stop后，其占用的端口通常不能立即释放，此时，supervisor以极快的速度试图重新拉起进程时，可能会由于报如下错误而导致几次retry均失败：
code class="hljs bash"code class="hljs vhdl"code class="hljs vbscript"## var/log/php-fpm.error.log
[18-Jul-2015 21:35:28] ERROR: unable to bind listening socket for address '127.0.0.1:9002': Address already in use (98)
[18-Jul-2015 21:35:28] ERROR: FPM initialization failed/code/code/code
而supervisor目前还不支持delay restart功能，因此，这里只能通过先sleep再启动的略显tricky的方法来解决问题，结果表明，疗效不错且无副作用。-_-
2) autorestart
其文档描述如下：
code class="hljs bash"code class="hljs vhdl"code class="hljs vbscript"code class="hljs livecodeserver"May be one of false, unexpected, or true. If false, the process will never be autorestarted. If unexpected, the process will be restart when the program exits with an exit code that is not one of the exit codes associated with this process’ configuration (see exitcodes). If true, the process will be unconditionally restarted when it exits, without regard to its exit code./code/code/code/code
其默认值是unexpected，表示若被监护进程的exit code异常时，supervisor才会重新拉起进程。这里设置为true，表明任何时候进程退出均会被再次拉起。
这样配置好后，在本文第1步搭建好的virtualenv环境中，运行如下命令即可完成supervisor对php-fpm master进程的监护：
code class="hljs bash"code class="hljs vhdl"code class="hljs vbscript"code class="hljs livecodeserver"code class="hljs avrasm"shell supervisord -c etc/sup.php-fpm.conf/code/code/code/code/code
然后，通过ps x | fgrep fpm可以看到，php-fpm主进程已经被拉起了。
然后，kill掉php-fpm主进程，再次ps x | fgrep fpm可以看到，一个新的php-fpm主进程会被supervisor创建出来。
至此，用supervisor守护php-fpm主进程以实现php-fpm的自动重启的需求已经解决了。
