將PHP從5.3.28升級到5.3.29時Nginx出現502錯誤

 　　這篇文章主要介紹了將PHP從5.3.28升級到5.3.29時Nginx出現502錯誤,需要的朋友可以參考下

　　今天將PHP從5.3.28升級到5.3.29，發現網站打不開了，提示”502 bad gateway”，訪問靜態資源可以，但訪問任何PHP檔案都會502。

　　其實之前也發現這個問題，只是一直沒找到解決辦法，所以我一直將PHP保持在5.3.28版本。

　　按照我以前的脾氣，我什麼軟體都得要最新的穩定版，但PHP之類的軟體是例外，因為版本高了，會導致很多程式不相容，相對來說5.3相容性算是最好的版本之一，當然5.2也可以。

　　強迫症實在受不了，官方說5.3.29是5.3的最後一個版本，最後一個版本出現這種問題又一直沒解決讓我很難受。

　　網上搜尋了一下，沒人出現我這種問題，所有的編譯過程，配置過程，都是照舊，之前從5.3.25一直到5.3.28都是用的我寫的同一個升級指令碼，按道理同一個子版本系列，一樣的編譯和配置過程，不應該出現問題的。

　　為何5.3.25一直到5.3.28都沒問題，到了5.3.29就沒問題了呢?

　　今天終於把問題的根源找到了，我也是醉了……

　　由於我不想佔用額外的連接埠，所以Nginx和PHP-FPM之間一直使用的Unix socket，而且據說這種方式效率也高一些。

　　PHP升級到5.3.29以後，出現502錯誤，而且是一開啟網頁就報錯了，不像是由於PHP執行逾時導致的Nginx提示502,更像是PHP-FPM異常終止了，或者是Ngxin根本沒有串連上fastcgi。

　　使用PHP-FPM的日誌也是鬱悶，我明明開啟了日誌，還設定了日誌路徑，但還是沒有組建記錄檔。

　　好吧，根據前面的思路推測出來的原因找問題：

　　1.PHP-FPM一開始工作就異常終止了;

　　2.Ngxin根本沒有串連上fastcgi。

　　第一種可能直接就排除了，因為出現502錯誤的時候，背景PHP-FPM進程並沒有退出，還存活得好好的。

　　那麼很可能是第二種可能了，我把Nginx和PHP-FPM的設定檔修改了一下，改成了傳統的“地址:連接埠”的形式

　　PHP-FPM設定檔中：

　　listen = 127.0.0.1:1234

　　Nginx設定檔中：

　　fastcgi_pass 127.0.0.1:1234

　　重啟服務，網站竟然順利開啟了。

　　看來就是Nginx沒有串連上PHP-FPM了，那麼問題出在哪裡呢?難道5.3.29去掉了Unix socket的串連方式?我覺得不大可能，查閱更新日誌，也沒有看到有關的項目啊。

　　我將Nginx和PHP-FPM的設定檔改回去。

　　PHP-FPM設定檔中：

　　listen = /tmp/php-cgi.sock

　　Nginx設定檔中：

　　fastcgi_pass unix:/tmp/php-cgi.sock;

　　重啟服務，立馬又502了。

　　首先想到了檢查許可權，反正是測試，所以我二話不說直接把那個PHP-FPM的sock檔案許可權改為777。

　　chmod 777 /tmp/php-cgi.sock

　　直接開啟網頁，能開啟!

　　好吧，就是許可權問題了，重啟服務，查看php-cgi.sock 的許可權

　　-rwx------. 1 root root 663 9月 18 00:16 php-cgi.sock

　　這。。。原因已經很明了了，怪不得Nginx連不上PHP-FPM，php-cgi.sock的許可權竟然是700，

　　但問題來了，為什麼同樣的編譯和配置過程，5.3.28之前的版本就沒問題呢?我查看另一台沒有升級5.3.29的伺服器：

　　srw-rw-rw- 1 root root 0 9月 16 21:11 php-cgi.sock

　　發現其許可權是666，這……無法理解了……為什麼5.3.28的預設許可權配置是666，到了5.3.29就變成700了呢?

　　查閱PHP文檔，找到解決辦法

　　將PHP-FPM裡的設定檔加入，前兩項是指定php-cgi.sock的擁有者和使用者組，後一項是指定檔案許可權。

　　listen.owner = www

　　listen.group = www

　　listen.mode = 0666

　　重啟服務，問題解決。