解决phpMyAdmin在nginx+php-fpm模式下无法使用的问题

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:
原创作品,允许转载,转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://dgd2010.blog.51cto.com/1539422/1684839

昨天接到一个网友的问题,说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--

本文出自 “通信,我的最爱” 博客,请务必保留此出处http://dgd2010.blog.51cto.com/1539422/1684839

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
2月前
|
设计模式 Java PHP
php设计模式--简单工厂模式(一)
php设计模式--简单工厂模式(一)
19 0
|
1天前
|
设计模式 算法 PHP
php模式
【7月更文挑战第18天】php模式
4 2
|
7天前
|
设计模式 中间件 PHP
探索PHP中的中间件模式
【7月更文挑战第12天】在现代的Web开发中,设计模式的应用对于代码的可维护性、扩展性和复用性至关重要。本文将深入探讨PHP语言中如何实现中间件模式,这是一种用于管理HTTP请求和响应的处理流程的设计模式。我们将通过具体示例来展示中间件模式如何在PHP项目中提升代码结构,并分析其在处理Web请求时的优势。
|
6天前
|
设计模式 开发框架 中间件
探索PHP中的中间件模式
【7月更文挑战第13天】在现代的Web开发中,设计模式扮演着至关重要的角色。本文将通过PHP语言的视角,深入探讨中间件模式的概念、实现及其在Web开发中的应用。我们将从中间件的定义开始,逐步过渡到如何在PHP框架中实现中间件,以及如何利用中间件来简化代码结构、增强应用的可扩展性和维护性。文章最后会提供一些实际案例,帮助读者更好地理解和运用中间件模式。
|
12天前
|
设计模式 中间件 PHP
深入理解PHP中的中间件模式
【7月更文挑战第7天】在Web开发的海洋中,PHP作为一艘灵活且强大的船,承载着无数的项目和解决方案。本文将揭开PHP中一个不为人知的角落——中间件模式,它如同船上的指南针,指引着请求的处理方向。我们将从中间件的定义出发,探索其在PHP中的应用实例,并深入分析其工作原理与实现方式,最终通过代码示例来揭示这一模式如何在实际应用中发挥巨大作用。文章旨在为读者提供对PHP中间件模式的全面认识,帮助开发者更好地利用这一模式优化项目架构。
|
8天前
|
设计模式 中间件 测试技术
PHP中的中间件模式解析与实践
【7月更文挑战第11天】在现代Web开发中,中间件模式已成为设计高效、可维护应用程序的关键。本文深入探讨了PHP环境下中间件模式的实现方法,并提供了一个实际示例来演示如何利用中间件优化请求处理流程。
13 1
|
8天前
|
存储 设计模式 监控
深入理解PHP中的中间件模式
【7月更文挑战第11天】本文将探索PHP中实现中间件模式的奥秘,从理论到实践,逐步剖析如何通过中间件提升代码的可维护性和扩展性。我们将摒弃传统的摘要形式,而是以一次虚拟的开发者对话引入话题,展现中间件在PHP项目中的应用价值和实现策略。
|
24天前
|
设计模式 监控 中间件
PHP中的中间件模式及其应用
【6月更文挑战第24天】在PHP开发中,中间件是一种设计模式,它允许开发者在请求处理流程的不同阶段插入自定义的处理逻辑。本文将介绍PHP中间件的概念、实现方式以及如何利用中间件提高代码的可维护性和扩展性。通过实际案例,我们将探索中间件在身份验证、日志记录和性能监控等方面的应用,并讨论如何在Laravel框架中有效使用中间件。
|
22天前
|
NoSQL 关系型数据库 MySQL
linux服务器重启php,nginx,redis,mysql命令
linux服务器重启php,nginx,redis,mysql命令
27 1
|
24天前
|
设计模式 中间件 API
PHP中的中间件模式及其应用
【6月更文挑战第24天】在现代Web开发中,设计模式的应用是提高代码可维护性和扩展性的关键。本文将深入探讨PHP中中间件模式的概念、实现方式以及在实际项目中的应用案例,旨在为开发者提供一种灵活处理HTTP请求和响应的有效手段。