解決phpMyAdmin在nginx+php-fpm模式下無法使用的問題

技術小胖子發表於2017-11-15
PHPNginx模式

昨天接到一個網友的問題，說yum安裝nginx+php-fpm+mysql+phpMyAdmin後，發現phpMyAdmin無法開啟，一直報502錯誤已經抓狂半天了，本著幫助別人快樂自己的原則，遠端幫他看了一下， 現記錄和總結如下，問題解決思路的總結放在文章最後，問題解決思路總結也是本文的重點。

問題環境：CentOS6通過yum安裝的nginx+php-fpm+mysql+phpMyAdmin

問題描述：安裝完成後發現nginx沒有問題，而phpMyAdmin無法開啟，提示502錯誤

問題解決過程

檢視問題環境的安裝包：

nginx-filesystem-1.0.15-12.el6.noarch
nginx-1.0.15-12.el6.x86_64
rrdtool-php-1.3.8-7.el6.x86_64
php-pear-1.9.4-4.el6.noarch
php-devel-5.3.3-46.el6_6.x86_64
php-mbstring-5.3.3-46.el6_6.x86_64
php-mcrypt-5.3.3-3.el6.x86_64
php-5.3.3-46.el6_6.x86_64
php-tidy-5.3.3-46.el6_6.x86_64
php-pecl-memcache-3.0.5-4.el6.x86_64
php-xmlrpc-5.3.3-46.el6_6.x86_64
php-xmlseclibs-1.3.1-3.el6.noarch
php-common-5.3.3-46.el6_6.x86_64
php-pdo-5.3.3-46.el6_6.x86_64
php-xml-5.3.3-46.el6_6.x86_64
php-fpm-5.3.3-46.el6_6.x86_64
php-cli-5.3.3-46.el6_6.x86_64
php-mysql-5.3.3-46.el6_6.x86_64
php-eaccelerator-0.9.6.1-1.el6.x86_64
php-gd-5.3.3-46.el6_6.x86_64

根據nginx報的502錯誤，可以初步判斷是upstream出現了問題，再提到upstream之前，先列一下nginx的配置檔案（去掉註釋，我已經將nginx記錄錯誤日誌的級別從預設級別提升到info）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
user              nginx;   
worker_processes  1;
error_log  /var/log/nginx/error.log info;
pid        /var/run/nginx.pid;
events {   
    worker_connections  1024;    
}
http {   
    include       /etc/nginx/mime.types;    
    default_type  application/octet-stream;
    client_max_body_size 10M;
    log_format  main  `$remote_addr - $remote_user [$time_local] "$request" `   
                      `$status $body_bytes_sent "$http_referer" `    
                      `"$http_user_agent" "$http_x_forwarded_for"`;
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;   
    keepalive_timeout  65;  
    include /etc/nginx/conf.d/*.conf;
}

由於此配置檔案中沒有顯式寫明任何server，因此需要檢視一下include /etc/nginx/conf.d/*.conf; 所包含的預設server檔案，即/etc/nginx/conf.d/default.conf，去掉註釋

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
cat /etc/nginx/conf.d/default.conf    
server {    
    listen       80 default_server;    
    server_name  _;  
    include /etc/nginx/default.d/*.conf;
    location / {   
        root   /usr/share/nginx/html;    
        index  index.php index.html index.htm;    
    }
    error_page  404              /404.html;   
    location = /404.html {    
        root   /usr/share/nginx/html;    
    }  
    error_page   500 502 503 504  /50x.html;    
    location = /50x.html {    
        root   /usr/share/nginx/html;    
    }
     location ~ [^/].php(/|$) {   
                fastcgi_split_path_info ^(.+?.php)(/.*)$;    
                if (!-f $document_root$fastcgi_script_name) {    
                        return 404;    
                }    
                fastcgi_pass 127.0.0.1:9000;    
                fastcgi_index index.php;    
                include fastcgi_params;    
     }    
}

初步判斷，此nginx的配置確實沒有問題，應該是php-fpm或者php本身的問題（縮小問題範圍）。

查閱nginx日誌檔案（/var/log/nginx/error.log），發現如下提示，確定是php-fpm的問題，fastcgi也算是對upstream的一種代理

1
2
3
4
5
6
7
8
9
10
11
2015/08/14 17:05:32 [notice] 9645#0: using the "epoll" event method   
2015/08/14 17:05:32 [notice] 9645#0: nginx/1.0.15    
2015/08/14 17:05:32 [notice] 9645#0: built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)     
2015/08/14 17:05:32 [notice] 9645#0: OS: Linux 2.6.32-504.el6.x86_64    
2015/08/14 17:05:32 [notice] 9645#0: getrlimit(RLIMIT_NOFILE): 65535:65535    
2015/08/14 17:05:32 [notice] 9646#0: start worker processes    
2015/08/14 17:05:32 [notice] 9646#0: start worker process 9648    
2015/08/14 17:05:36 [error] 9648#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"    
2015/08/14 17:09:22 [error] 9648#0: *4 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"    
2015/08/14 17:11:23 [error] 9648#0: *7 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.228, server: 192.168.1.101, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.101"    
2015/08/14 17:11:33 [info] 9648#0: *9 client closed prematurely connection while reading client request line, client: 192.168.1.228, server: 192.168.1.101

建立一個能開啟phpinfo的檔案，檢視php檔案能否正確解析（進一步縮小問題範圍）

發現php-fpm能正常解析php檔案，裡面的各個php元件都顯示正常

檢視phpMyAdmin的版本，查閱官方網站的文件看看是否支援php5.3.3，發現當前的phpMyAdmin支援，因此應該不是phpMyAdmin的問題

開始檢查php-fpm的日誌（/var/log/php-fpm/error.log），發現如下所示：

1
2
3
4
5
6
7
8
[14-Aug-2015 16:34:53] NOTICE: fpm is running, pid 9522   
[14-Aug-2015 16:34:53] NOTICE: ready to handle connections    
[14-Aug-2015 16:43:54] WARNING: [pool www] child 9527 exited on signal 11 (SIGSEGV) after 541.401349 seconds from start    
[14-Aug-2015 16:43:55] NOTICE: [pool www] child 9614 started    
[14-Aug-2015 16:44:00] WARNING: [pool www] child 9526 exited on signal 11 (SIGSEGV) after 547.107407 seconds from start    
[14-Aug-2015 16:44:00] NOTICE: [pool www] child 9615 started    
[14-Aug-2015 17:05:36] WARNING: [pool www] child 9523 exited on signal 11 (SIGSEGV) after 1843.098829 seconds from start    
[14-Aug-2015 17:05:36] NOTICE: [pool www] child 9649 started

這個日誌顯然不足以提供足夠的資訊來解決問題，因此修改php-fpm和php.ini對日誌級別的一些引數配置，以提升日誌級別，獲取詳細的錯誤資訊。

搜尋配置檔案的中log關鍵字，或者根據文件或資料修改，一些方法或步驟如下：

/etc/php-fpm.conf檔案，將日誌級別從notice改動到debug

1
log_level = debug

/etc/php-fpm.d/www.conf檔案，將php worker的標準輸出和錯誤輸出從/dev/null 重定向到主要的錯誤日誌中，即/var/log/php-fpm/error.log

1
catch_workers_output = yes

/etc/php.ini檔案

1
2
3
4
5
6
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On
display_startup_errors = On
log_errors = On
track_errors = On
html_errors = On

再次重新啟動php-fpm，發現worker中的詳細錯誤：

1
2
3
4
5
6
7
8
9
[14-Aug-2015 17:09:18] NOTICE: fpm is running, pid 9672   
[14-Aug-2015 17:09:18] NOTICE: ready to handle connections    
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: "[Fri Aug 14 17:09:22 2015"    
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: "] [notice] EACCELERATOR(9673): PHP crashed on opline 30 of PMA_URL_getCommon() at /usr/share/nginx/html/libraries/url_generating.lib.php:188"    
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 said into stderr: ""    
[14-Aug-2015 17:09:22] WARNING: [pool www] child 9673 exited on signal 11 (SIGSEGV) after 4.286828 seconds from start    
[14-Aug-2015 17:09:22] NOTICE: [pool www] child 9679 started    
[14-Aug-2015 17:11:23] WARNING: [pool www] child 9675 said into stderr: "[Fri Aug 14 17:11:23 2015"    
[14-Aug-2015 17:11:23] WARNING: [pool www] child 9675 said into stderr: "] [notice] EACCELERATOR(9675): PHP crashed on opline 30 of PMA_URL_getCommon() at /usr/share/nginx/html/libraries/url_generating.lib.php:188"

錯誤資訊中提到EACCELERATOR這個php模組，因此先確定一下是不是由於這個模組有問題，因此，先將此模組禁用，方法是將/etc/php.d/eaccelerator.ini檔案更改個字尾名稱，例如mv /etc/php.d/eaccelerator.ini /etc/php.d/eaccelerator.ini~，然後重啟php-fpm，再校驗一下結果，發現問題已經解決。

可能是eaccelerator與phpMyAdmin衝突的原因，因此要想使用phpMyAdmin可以將此模組禁用，或者安裝時跳過這個包。

註釋：eAccelerator是一個自由開放原始碼php加速器，優化和動態內容快取，提高了php指令碼的快取效能，使得PHP指令碼在編譯的狀態下，對伺服器的開銷幾乎完全消除。它還有對指令碼起優化作用，以加快其執行效率。使PHP程式程式碼執效率能提高1-10倍。（來自bdbk）

問題解決思路總結

第0條，溝通是診斷故障的關鍵，詳細瞭解問題始末，例如部署方案，步驟，做了哪些操作等

第一，根據經驗判斷，nginx+php-fpm+phpMyAdmin是很牢靠的組合，因此判斷這是個例問題，而不是批量問題，因此直接開始動手，登入到系統中檢視安裝的軟體包，nginx、php和phpMyAdmin版本都是要檢視的，此步驟有助於根據掌握的知識和經驗，初步判斷是否相互相容，是否有未修復bug等。

第二，執行nginx -t檢查nginx的配置檔案有無顯式錯誤，檢查nginx執行狀態

第三，執行php-fpm -t檢查php-fpm的配置檔案有無顯式錯誤，檢查php-fpm的執行狀態

第四，檢查錯誤日誌，先檢查nginx的錯誤日誌，因為它是“第一現場”，再檢查php-fpm日誌，因為它是“第二現場”

第五，如果日誌提示明顯，則按照日誌提示，修改相應的配置檔案，再次驗證問題

第六，如果依然有問題，則本步驟就是解決問題的最關鍵的步驟，需要提升記錄日誌的級別，這也就是為什麼有debug為什麼叫做除錯，將nginx的日誌級別提升到info（為什麼不能提升到debug，nginx編譯時有個–debug選項，不確定時可以不用），將php的日誌級別提升到debug，開啟所有的php除錯開關

第七，重新啟動nginx和php-fpm後，配置檔案生效，重新開啟網頁重現問題，再次開啟日誌，根據日誌提示內容再次，修改相應的配置檔案，再次驗證問題

第八，如果反覆修改無果後，該查閱官方手冊就查閱官方手冊，該Google 搜尋就Google搜尋，該反饋bug就反饋bug，如果持續無果，則換種解決問題的方式，尋找正確的解決方案，參照如下：

  • 參考已有的成功的版本組合，更換版本組合或者修改配置檔案，消除環境差異性，適用於快速解決問題

  • 將yum安裝改為編譯安裝，或者yum安裝更少的包，以最小化的安裝方式將問題範圍縮減到最小，從而確定問題，提升解決問題的能力，適用於研究和學習

最後補充一句：只要出現的問題能夠重現，而不是隨機出現，則就一定能很好的解決，因此不要慌，也不要浮躁，更不要放棄，甚至可以緩一緩後再冷靜處理。

–end–

本文轉自 urey_pp 51CTO部落格，原文連結：http://blog.51cto.com/dgd2010/1684839，如需轉載請自行聯絡原作者


相關文章