phpfpm停止

① Linux下php日誌報錯，各位大蝦，看看。。。然後php-fpm進程會時不時掛掉

大概是因為程序有bug吧，建議改一下代碼。

② Starting php-fpm ................................... failed

參考地址；網頁鏈接

把php-fpm.conf的pid那一行開頭的;刪掉。

③ 如何關閉php-fpm進程

如果把php-fpm已經安裝了一個系統服務，那就：service php-fpm stop來關閉
如果沒有的話，直接通過萬能的方法：殺死對應的進程。
要關閉php-fpm進程，就殺死它：pkill -9 php-fpm

④ php-fpm 沒有響應，僵死，求教

日誌提示明顯是腳本執行超時，這些問題通常出現的原因有:
1、大量的IO操作(文件讀寫、資料庫操作等),代碼循環邏輯沒控制好，執行時間超時;
2、系統的負載過高，腳本受阻塞長時間等待超時;
3、php環境沒配置好。

⑤ docker php-fpm 一直重啟問題處理

使用 docker-compose up -d 啟動 php-fpm 容器後會發現容器成功啟動之後會馬上關閉。由於設置了 restart: always 會導致容器再次啟動然後關閉

官方 php-fpm : 7.1 鏡像，使用自定義的 php-fpm 配置。
php-fpm 配置是從現有生產伺服器上復制過來的。配置沒有問題。

看log，發現fpm正常啟動了，然後馬上就退出

跟鏡像中自帶的 php-fpm.conf 比較發現鏡像中使用 daemonize = no ，而我自定義配置中 daemonize = yes 是後台運行的。
那麼很明顯官方鏡像是故意使用 daemonize = no 不讓 fpm 在後台中運行，進而阻止容器退出

修改 php-fpm.conf 中如下
daemonize = no

⑥ 如何關閉php-fpm進程

可以去/etc/init.d/目錄下看看有沒有php5.4-fpm或php7.0-fpm這種文件,如果有,可以用service php5.4-fpm stop這種方式停掉服務就可以了，如果還有不明白的話，你可以在後盾人看看視頻找找答案，有空多看看時間長了，慢慢就明白了，希望能幫到你，給個採納吧謝謝(ಡωಡ)hiahiahia

⑦ php-fpm的簡介

PHP-FPM(FastCGI Process Manager：FastCGI進程管理器)對於PHP 5.3.3之前的php來說，是一個補丁包 ，旨在將FastCGI進程管理整合進PHP包中。如果你使用的是PHP5.3.3之前的PHP的話，就必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。
從PHP 5.4 RC2開始，php-fpm已經轉正了，不再被php團隊標注為EXPERIMENTAL（實驗性的東西） 。
相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。
PHP5.3.3已經集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，可以有效控制內存和進程、可以平滑重載PHP配置，比spawn-fcgi具有更多優點，所以被PHP官方收錄了。在./configure的時候帶 –enable-fpm參數即可開啟PHP-FPM。
使用PHP-FPM來控制PHP-CGI的FastCGI進程
/usr/local/php/sbin/php-fpm{start|stop|quit|restart|reload|logrotate}
--start 啟動php的fastcgi進程
--stop 強制終止php的fastcgi進程
--quit 平滑終止php的fastcgi進程
--restart 重啟php的fastcgi進程
--reload 重新平滑載入php的php.ini
--logrotate 重新啟用log文件

⑧ 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()，具體邏輯這里不再展開，比較容易理解。

原文出處： https://www.fanhao.com/2017/10/internal-php-fpm.html