Que dois-je faire si phpMyAdmin ne peut pas être utilisé en mode nginx+php-fpm ?

Ce qui suit est introduit par phpmyadmin à l'aide de la colonne tutoriel phpMyAdmin est La solution de ne peut pas être utilisée en mode nginx+php-fpm. J'espère qu'elle sera utile aux amis dans le besoin !

J'ai reçu une question d'un internaute hier, disant qu'après yum, j'ai installé nginx+php-fpm+mysql+phpMyAdmin , j'ai découvert que phpMyAdmin ne peut pas être ouvert et qu'il continue de signaler des erreurs 502 pendant une longue période. Conformément au principe d'aider les autres à être heureux, je l'ai aidé à le vérifier à distance. Les enregistrements et les résumés sont les suivants. Les idées de résolution de problèmes sont placées à la fin de l'article. Le résumé des idées de résolution de problèmes est également l'objet de cet article.

Recommandé : "Tutoriel d'utilisation de phpmyadmin"

Environnement problématique : CentOS6 nginx+php-fpm+mysql+phpMyAdmin installé via yum

Description du problème : Une fois l'installation terminée, il s'avère qu'il n'y a aucun problème avec nginx, mais phpMyAdmin ne peut pas être ouvert, provoquant une erreur 502

Résolution du problème processus

Vérifiez le package d'installation de l'environnement problématique :

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

Sur la base de l'erreur 502 signalée par nginx, on peut dans un premier temps juger qu'il y a un problème avec l'amont. Avant de mentionner l'amont, listons le fichier de configuration nginx (supprimons les commentaires. J'ai augmenté le niveau du journal des erreurs nginx de. le niveau par défaut à 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;
}

Étant donné qu'aucun serveur n'est explicitement indiqué dans ce fichier de configuration, vous devez vérifier le fichier de serveur par défaut inclus dans include /etc/nginx/conf.d/*.conf;, qui est /etc/nginx / conf.d/default.conf, supprimez le commentaire

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

Le jugement préliminaire montre qu'il n'y a effectivement aucun problème avec la configuration de nginx, et cela devrait être un problème avec php-fpm ou php lui-même (réduisant la portée de le problème).

Vérifiez le fichier journal nginx (/var/log/nginx/error.log) et recherchez l'invite suivante. Il s'agit certainement d'un problème avec php-fpm qui peut également être considéré comme un proxy pour l'amont<.>

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

Créez un fichier qui peut ouvrir phpinfo et vérifiez si le fichier php peut être analysé correctement (réduisant encore la portée du problème)

J'ai constaté que php-fpm peut analyser les fichiers php normalement, et tous les composants php à l'intérieur sont affichés normalement

Vérifiez la version de phpMyAdmin, consultez la documentation du site officiel pour voir s'il prend en charge php5.3.3, et constatez que le phpMyAdmin actuel le prend en charge, cela ne devrait donc pas être un problème avec phpMyAdmin

Commencez à vérifier le journal php-fpm (/var/log /php-fpm/error.log), et trouvez ce qui suit :

[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

Ce journal n'est évidemment pas suffisant pour fournir suffisamment informations pour résoudre le problème, modifiez donc certains paramètres du niveau de journalisation dans php-fpm et php.ini Configure pour augmenter le niveau de journalisation et obtenir des informations détaillées sur l'erreur.

Recherchez le mot-clé log dans le fichier de configuration, ou modifiez-le en fonction de la documentation ou des informations. Certaines méthodes ou étapes sont les suivantes :

fichier/etc/php-fpm.conf, modifier le niveau de journalisation de notice Accédez au fichier debug

log_level = debug

/etc/php-fpm.d/www.conf et redirigez la sortie standard et la sortie d'erreur du travailleur php de /dev/null vers le principal journal des erreurs, qui est le fichier /var/ log/php-fpm/error.log

catch_workers_output = yes

/etc/php.ini

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

Redémarrez php-fpm à nouveau et recherchez l'erreur détaillée dans le work:

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

Le message d'erreur mentionne le module php EACCELERATOR, alors déterminez d'abord s'il y a un problème avec ce module. Par conséquent, désactivez d'abord ce module en changeant le nom du suffixe du /etc/php.d/. eaccelerator.ini. Par exemple, mv /etc/php.d/eaccelerator.ini /etc/php.d/eaccelerator.ini~, puis redémarrez php-fpm, vérifiez à nouveau les résultats et constatez que le problème a été résolu. .

Il se peut qu'eaccelerator entre en conflit avec phpMyAdmin, donc si vous souhaitez utiliser phpMyAdmin, vous pouvez désactiver ce module ou ignorer ce package lors de l'installation.

Remarque : eAccelerator est un accélérateur PHP gratuit et open source qui optimise la mise en cache dynamique du contenu, améliore les performances de mise en cache des scripts PHP et élimine presque complètement la surcharge du serveur des scripts PHP à l'état compilé. Il optimise également les scripts pour accélérer leur efficacité d'exécution. Améliorez l'efficacité de l'exécution du code du programme PHP de 1 à 10 fois. (de bdbk)

Résumé des idées de résolution de problèmes

Article 0, la communication est la clé pour diagnostiquer les défauts en détail, comme le déploiement. plan, étapes, quelles opérations ont été effectuées, etc.

Premièrement, d'après l'expérience, nginx+php-fpm+phpMyAdmin est une combinaison très fiable, donc je juge qu'il s'agit d'un problème de cas, ce n'est pas un problème de lot, alors commencez directement. Commencez par vous connecter au système pour vérifier les packages logiciels installés. Vous devez vérifier les versions de nginx, php et phpMyAdmin. Cette étape vous aidera à faire un jugement préliminaire basé sur vos connaissances et votre expérience. ils sont compatibles entre eux et s'il y a des bugs non corrigés, etc.

Deuxièmement, exécutez nginx -t pour vérifier s'il y a des erreurs explicites dans le fichier de configuration nginx et vérifiez l'état d'exécution de nginx

Troisièmement, exécutez php-fpm -t pour vérifier la configuration fichier de php-fpm S'il y a des erreurs explicites, vérifiez l'état d'exécution de php-fpm

Quatrièmement, vérifiez le journal des erreurs. Vérifiez d'abord le journal des erreurs nginx car il s'agit du "premier site", puis. vérifiez le journal php-fpm car c'est la "deuxième scène"

Cinquièmement, si l'invite du journal est évidente, suivez l'invite du journal, modifiez le fichier de configuration correspondant et vérifiez à nouveau le problème

Sixièmement, s'il y a toujours un problème, alors

Cette étape est l'étape la plus critique pour résoudre le problème. C'est pourquoi le débogage est appelé . niveau de nginx vers info (pourquoi ne peut-il pas être mis à niveau vers debug ? nginx Il existe une option --debug lors de la compilation (vous n'avez pas besoin de l'utiliser si vous n'êtes pas sûr). Augmentez le niveau de journalisation php pour déboguer et activez tous les commutateurs de débogage php

Septièmement, après avoir redémarré nginx et php-fpm, configurez le fichier prend effet, rouvrez la page Web pour reproduire le problème, ouvrez à nouveau le journal, modifiez le fichier de configuration correspondant en fonction du journal » vous invite et vérifiez à nouveau le problème

Huitièmement, si les modifications répétées échouent, il est temps de consulter le manuel officiel Consultez le manuel officiel Si vous effectuez une recherche sur Google, recherchez sur Google. Si vous signalez un bug, signalez-le. un bug. Si cela continue à échouer, essayez une autre façon de résoudre le problème et trouvez la bonne solution. Veuillez vous référer à ce qui suit :

• Référez-vous aux combinaisons de versions réussies existantes, changez de version. combinaisons ou modifier les fichiers de configuration pour éliminer les différences environnementales, ce qui convient pour résoudre rapidement les problèmes

• Changez l'installation de yum en installation compilée, ou installez yum avec moins de packages pour réduire l'étendue du problème au minimum avec une méthode d'installation minimale, identifiant ainsi le problème et améliorant la capacité de le résoudre. problème. Il convient à la recherche et à l'étude

Enfin, tant que le problème peut être reproduit et n'apparaît pas au hasard, il sera définitivement résolu, alors ne paniquez pas et ne soyez pas impétueux. Plus N'abandonnez pas, peut-être même y allez-y doucement, puis traitez-le calmement.

--fin--

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!