将PHP从5.3.28升级到5.3.29时Nginx出现502错误，5.3.29nginx

将PHP从5.3.28升级到5.3.29时Nginx出现502错误，5.3.29nginx

今天将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
重启服务，问题解决。