今天将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
重启服务,问题解决。
将PHP从5.3.28升级到5.3.29时Nginx出现502错误
- Author -
mdxy-dxy声明:登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述。
Reply on: @reply_date@
@reply_contents@