What should I do if phpMyAdmin cannot be used in nginx+php-fpm mode?

The following is introduced by phpmyadmin##Using Tutorial ColumnphpMyAdmin in The solution cannot be used in nginx php-fpm mode. I hope it will be helpful to friends in need!

Received a question from a netizen yesterday, saying that after yum installed nginx php-fpm mysql phpMyAdmin, it was found that phpMyAdmin could not be opened. , I have been reporting 502 errors for a long time. In line with the principle of helping others to be happy, I helped him check it remotely. The records and summaries are as follows. The summary of problem-solving ideas is placed at the end of the article. The summary of problem-solving ideas is also included in this article. focus.

Recommended: "

phpmyadmin usage tutorial"

Problem environment: CentOS6 nginx php-fpm mysql phpMyAdmin## installed through yum

#Problem description:

After the installation is completed, it is found that there is no problem with nginx, but phpMyAdmin cannot be opened, prompting a 502 error

Problem solving process

View the problem environment Installation package:

nginx-filesystem-1.0.15-12.el6.noarch##nginx-1.0.15- 12.el6.x86_64rrdtool-php-1.3.8-7.el6.x86_64##php-5.3.3-46. el6_6.x86_64php-tidy-5.3.3-46.el6_6.x86_64php-pecl-memcache-3.0.5- 4.el6.x86_64php-xmlrpc-5.3.3-46.el6_6.x86_64php-xmlseclibs-1.3.1- 3.el6.noarchphp-common-5.3.3-46.el6_6.x86_64php-pdo-5.3.3- 46.el6_6.x86_64php-xml-5.3.3-46.el6_6.x86_64##php-fpm-5.3.3- 46.el6_6.x86_64php-cli-5.3.3-46.el6_6.x86_64##php-mysql-5.3.3- 46.el6_6.x86_64php-eaccelerator-0.9.6.1-1.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-gd-5.3.3- 46.el6_6.x86_64

Based on the 502 error reported by nginx, we can initially judge that there is a problem with upstream. Before mentioning upstream, let’s list the nginx configuration file (remove the comments. I have raised the level of nginx error log from the default level to info).

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;
}

Since no server is explicitly stated in this configuration file, you need to check the default server file included in include /etc/nginx/conf.d/*.conf;, which is /etc/nginx /conf.d/default.conf, remove the comment

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;    
     }    
}

Preliminary judgment shows that there is indeed no problem with the configuration of nginx. It should be a problem with php-fpm or php itself (narrowing the scope of the problem).

Check the nginx log file (/var/log/nginx/error.log) and find the following prompt. It is definitely a problem with php-fpm. Fastcgi can also be regarded as a proxy for upstream

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

Create a file that can open phpinfo and check whether the php file can be parsed correctly (further narrowing the scope of the problem)

Found that php-fpm can parse the php file normally, and all the php components inside are displayed normally

Check the version of phpMyAdmin, check the official website documentation to see if it supports php5.3.3, and found that the current phpMyAdmin supports it, so it should not be a problem with phpMyAdmin

Start checking the php-fpm log (/var/log /php-fpm/error.log) and found the following:

[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

This log is obviously not enough to provide enough information to solve the problem, so modify some parameters of the log level in php-fpm and php.ini Configure to increase the log level and obtain detailed error information.

Search for the log keyword in the configuration file, or modify it according to the documentation or information. Some methods or steps are as follows:

/etc/php-fpm.conf file, change the log level from notice Go to the debug

log_level = debug

/etc/php-fpm.d/www.conf file and redirect the standard output and error output of the php worker from /dev/null to the main error log, which is /var/ log/php-fpm/error.log

catch_workers_output = yes

/etc/php.ini file

error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On
display_startup_errors = On
log_errors = On
track_errors = On
html_errors = On

Restart php-fpm again and find detailed errors in the worker:

[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"

The error message mentions the EACCELERATOR php module, so first determine if there is a problem with this module. Therefore, first disable this module by changing the suffix name of the /etc/php.d/eaccelerator.ini file. For example, mv /etc/php.d/eaccelerator.ini /etc/php.d/eaccelerator.ini~, then restart php-fpm, check the results again, and find that the problem has been solved.

It may be that eaccelerator conflicts with phpMyAdmin, so if you want to use phpMyAdmin, you can disable this module or skip this package during installation.

Note: eAccelerator is a free and open source PHP accelerator that optimizes and dynamic content caching, improves the caching performance of PHP scripts, and almost completely eliminates the server overhead of PHP scripts in the compiled state. It also optimizes scripts to speed up their execution efficiency. Improve PHP program code execution efficiency by 1-10 times. (from bdbk)

Summary of problem solving ideas

Article 0, communication is the key to diagnosing faults. Understand the problem in detail, such as deployment plan, steps , what operations have been done, etc.

First, based on experience, nginx php-fpm phpMyAdmin is a very reliable combination, so I judge that this is an individual problem, not a batch problem, so I started directly. Log in to the system to check the installed software packages. You need to check the versions of nginx, php and phpMyAdmin. This step will help you make a preliminary judgment based on your knowledge and experience to determine whether they are compatible with each other and whether there are unfixed bugs, etc.

Second, execute nginx -t to check whether there are explicit errors in the nginx configuration file and check the running status of nginx

Third, execute php-fpm -t to check the configuration file of php-fpm If there are any explicit errors, check the running status of php-fpm

Fourth, check the error log, first check the nginx error log, because it is the "first site", and then check the php-fpm log, because It is the "second scene"

Fifth, if the log prompt is obvious, follow the log prompt, modify the corresponding configuration file, and verify the problem again

Sixth, if there is still a problem, then This step is the most critical step to solve the problem. It is necessary to increase the level of logging. This is why debug is called debugging. . Increase the log level of nginx to info (why it cannot be upgraded to debug, nginx There is a --debug option when compiling (you don’t need to use it if you are not sure). Increase the php log level to debug and turn on all php debugging switches.

Seventh, after restarting nginx and php-fpm, configure The file takes effect, reopen the webpage to reproduce the problem, open the log again, modify the corresponding configuration file according to the log prompts, and verify the problem again

Eighth, if repeated modifications fail, it is time to consult the official manual Consult the official manual. If you search on Google, search on Google. If you report a bug, report a bug. If it continues to be fruitless, try another way to solve the problem and find the correct solution. Please refer to the following:

• Refer to existing successful version combinations, change the version combination or modify the configuration file to eliminate environmental differences, which is suitable for quickly solving problems

• Change the yum installation to compiled installation, or yum installs fewer packages to reduce the scope of the problem to the minimum with a minimal installation method, thereby identifying the problem and improving the ability to solve the problem. It is suitable for Research and study

Finally add a word: As long as the problem can be reproduced and does not appear randomly, it will definitely be solved well, so don’t panic or be impetuous. Don't give up, maybe even take it slow and then deal with it calmly.

--end--

The above is the detailed content of What should I do if phpMyAdmin cannot be used in nginx+php-fpm mode?. For more information, please follow other related articles on the PHP Chinese website!