Résolution des problèmes avec Apache
1.
Vérification des logs
Si quelque chose cloche avec votre Apache alors que vous n'avez aucune idée de
ce que ça peut être, vous trouverez certainement des indices dans les fichiers
de logs (N.D.T. : journaux où est enregistré l'activité de l'application).
Il y a plusieurs fichiers de logs différents, mais certains d'entre eux peuvent
ne pas être présents sur votre système selon les modules que vous avez activés.
En principe, ils se trouvent dans /var/log/apache2/.
access_log et ssl_access_log
Exemple de code 1.1 : access_log |
67.185.0.236 - - [18/Jun/2005:12:05:50 -0700] "GET / HTTP/1.0" 200 721
10.0.1.80 - - [18/Jun/2005:12:11:07 -0700] "GET /~jaspenelle/__journal1.jpg HTTP/1.1" 200 19079
66.239.233.163 - - [18/Jun/2005:12:15:06 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.0" 200 1661
67.185.60.155 - - [18/Jun/2005:12:18:48 -0700] "GET / HTTP/1.0" 200 721
67.185.0.236 - - [18/Jun/2005:12:25:39 -0700] "GET / HTTP/1.0" 200 721
10.0.1.80 - - [18/Jun/2005:12:28:04 -0700] "GET /~jaspenelle/avy14.gif HTTP/1.1" 200 1661
10.0.1.80 - - [18/Jun/2005:12:28:46 -0700] "GET /~jaspenelle/avy7.png HTTP/1.1" 200 13066
|
Ce fichier contient simplement la liste de chaque fichier demandé à votre
serveur. À moins que vous ayiez changé la configuration par défaut, les lignes
sont en Common Log Format :
Exemple de code 1.2 : Syntaxe du Common Log Format |
adresseclient rfc931 utilisateur [date] "requête" statut octets
|
| adresseclient |
Nom d'hôte ou adresse IP du client qui a fait la requête. |
| rfc931 |
L'identifiant distant du client qui a fait la requête. |
| utilisateur |
L'identifiant qu'a donné l'utilisateur pour s'identifier sur la page. |
| [date] |
Date et heure de la requête. |
| "requête" |
La requête complète telle qu'envoyée par le client. |
| statut |
Le code de retour HTTP renvoyé au client pour indiquer le statut de la
réponse.
|
| octets |
La taille du document transféré (en-tête « content-length »).
|
error_log et ssl_error_log
Exemple de code 1.3 : error_log |
[Mon Feb 07 23:33:18 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
[Mon Feb 07 23:33:18 2005] [notice] Digest: generating secret for digest authentication ...
[Mon Feb 07 23:33:18 2005] [notice] Digest: done
[Mon Feb 07 23:33:18 2005] [notice] Apache/2.0.52 (Gentoo/Linux) PHP/4.3.10 configured -- resuming normal operations
[Sat Jun 18 13:01:54 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:14 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:18 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:21 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
[Sat Jun 18 13:02:24 2005] [error] [client 10.0.1.80] File does not exist: /var/www/localhost/htdocs/favicon.ico
|
Comme vous le voyez, ce fichier peut contenir beaucoup de choses, selon la
valeur de la directive ErrorLevel dans votre fichier
httpd.conf. Il vous indique si Apache a démarré correctement,
quelles sont les erreurs rencontrées... C'est lui qui vous dira si quelque chose
se passe mal en général. Si quelque chose ne fonctionne pas, il est le premier
fichier à consulter.
suexec_log
Exemple de code 1.4 : suexec_log |
[2005-02-11 22:33:19]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
[2005-03-11 19:20:13]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
[2005-03-11 19:34:47]: uid: (1000/vericgar) gid: (1000/1000) cmd: test.cgi
|
Ce fichier contient une entrée pour chaque fois qu'un script est lancé en
utilisant CGI et suexec. Si vous n'arrivez pas à faire fonctionner un script
avec suexec, ce fichier est celui à consulter car il contiendra en principe une
ligne indiquant pourquoi il n'a pas pu lancer le script.
2.
J'ai installé un module Apache, mais il ne marche pas !
Installer le module ne suffit pas, il faut également l'activer. Nous procédons
ainsi pour pouvoir facilement activer et désactiver les modules
individuellement, pour les tester un par un en cas de problème afin de trouver
celui qui cloche.
Lorsque vous installez un module, il devrait y avoir un message dans ce
genre :
Exemple de code 2.1 : Message post-installation (emerge) |
*
* To enable mod_layout, you need to edit your /etc/conf.d/apache2 file and
* add '-D LAYOUT' to APACHE2_OPTS.
*
*
* Configuration file installed as
* /etc/apache2/modules.d/15_mod_layout.conf
* You may want to edit it before turning the module on in /etc/conf.d/apache2
*
|
Si vous comprenez un minimum l'anglais, il suffit de faire exactement ce qui est
indiqué pour activer le module. Pour les autres, il suffit de rajouter -D
LAYOUT à la variable APACHE2_OPTS qui se trouve dans le fichier
/etc/conf.d/apache2 pour activer mod_layout.
Si vous avez loupé ce message, il existe un moyen simple de savoir ce qu'il faut
ajouter à APACHE2_OPTS dans /etc/conf.d/apache2 :
ouvrez le fichier de configuration du module installé par l'ebuild et vous
verrez quelle variable est testée par IfDefine. Il suffit alors de la
déclarer dans APACHE2_OPTS. Les fichiers de configuration des modules Apache se
trouvent dans /etc/apache2/modules.d/.
Exemple de code 2.2 : Un extrait de 15_mod_layout.conf |
<IfDefine LAYOUT>
<IfModule !mod_layout.c>
LoadModule layout_module modules/mod_layout.so
</IfModule>
</IfDefine>
|
Ce qui se trouve dans le bloc IfDefine est exécuté si vous ajoutez -D
LAYOUT au fichier /etc/conf.d/apache2. LAYOUT n'est
qu'un exemple.
La variable APACHE2_OPTS accepte plusieurs autres options qui sont
spécifiées dans la configuration par défaut et détaillées dans
/etc/conf.d/apache2.
La documentation concernant tous les modules de base se trouve dans la documentation Apache 2.0.
3.
Apache renvoie des pages vides, Apache plante
Cela arrive surtout lors des mises à jour car la compatibilité des binaires est
rompue dans APR (ce qui peut arriver pour un nombre certain de raisons). Pour
corriger le problème, il faut recompiler Apache et ses outils :
Exemple de code 3.1 : Recompiler Apache et ses outils |
# emerge -aCv '=www-servers/apache-2*'
# emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'
# emerge -av '=www-servers/apache-2*'
$ equery depends www-servers/apache
[ Searching for packages depending on www-servers/apache... ]
dev-php/phpsysinfo-2.3-r2
dev-php/phpsysinfo-2.1-r2
dev-lang/php-5.2.4_p20070914-r2
net-www/mod_layout-4.0.1a-r1
www-servers/gorg-0.5
# emerge -av '=dev-lang/php-5.2.4_p20070914-r2' '=net-www/mod_layout-4.0.1.a-r1'
|
Détecter un module bogué
Si vous rencontrez toujours des problèmes après avoir suivi les instructions
ci-dessus, le coupable est très certainement un des modules additionnels
chargé par Apache.
Commencez par désactiver tous les modules additionnels et redémarrez Apache.
Exemple de code 3.2 : Désactiver les modules additionnels |
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"
APACHE2_OPTS=""
|
Exemple de code 3.3 : Redémarrer Apache |
# /etc/init.d/apache2 stop
# ps -A
# /etc/init.d/apache2 start
|
Note :
Vous devrez peut-être modifier votre configuration d'Apache si vous y avez
ajouté des Directives fournies par un de ces modules sans faire de test
pour savoir si le module était bien chargé. D'une manière générale, il vaut
mieux placer ces directives dans des blocs qui testent la présence du module en
mémoire. Vous pouvez vous inspirer des fichiers .conf situés dans le répertoire
/etc/apache2/modules.d pour des exemples.
|
Si Apache arrête enfin de crasher ou de renvoyer des pages blanches, le problème
venait bien de l'un des modules qui ont été désactivés. Pour trouver duquel cela
provient, nous allons les réactiver un par un en redémarrant Apache à chaque
fois.
Une fois que vous avez trouvé quel module était responsable, une simple
recompilation du module en question peut résoudre le problème.
Si Apache ne fonctionne toujours pas correctement une fois que le module a été
réinstallé, alors ouvrez un bogue en
donnant les versions et révisions exactes du module et en précisant exactement
ce qui ne va pas. Cherchez d'abord si le problème n'aurait pas déjà été
décrit !
4.
Le serveur n'interprète pas le code PHP ou les scripts CGI et renvoie
directement le source à la place
Il arrive qu'Apache renvoie le code PHP ou CGI au lieu d'exécuter les scripts et
de ne renvoyer que le résultat. Si cela arrive même lorsque le module est activé
dans /etc/conf.d/apache2, il se peut que ce soit un problème de
cache. Effacer le cache du navigateur web peut résoudre le problème.
Parfois le problème n'apparaît que si l'on accède au site par son adresse IP au
lieu de son nom ou vice-versa. Dans ce cas, il s'agit très certainement d'un
problème de cache.
5.
configure: error: changes in the environment can compromise the build
Si vous obtenez cette erreur, il se peut que votre variable CFLAGS
dans /etc/make.conf contienne des espaces en trop. Ceci est simple
à corriger :
Exemple de code 5.1 : Exemple de correction pour /etc/make.conf |
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3 -pipe"
|
6.
Address already in use: make_sock: could not bind to address
0.0.0.0:443
Cette erreur apparaît lors du démarrage et provient du fait qu'il y a plusieurs
directives Listen incompatibles dans la configuration du serveur. Pour
résoudre ce problème, cherchez toutes les directives Listen et résolvez
le problème.
Exemple de code 6.1 : Trouver toutes les directives Listen |
# cd /etc/apache2/
# grep Listen httpd.conf vhosts.d/*.conf modules.d/*.conf
|
Il s'agit maintenant de repérer les conflits qu'il pourrait y avoir au niveau
des ports ouverts par Apache. Par exemple, s'il y a une ligne Listen 80
dans httpd.conf et une ligne Listen 10.0.0.15:80 dans un
autre fichier, alors Apache ne pourra pas démarrer. Dans ce cas, Apache ouvrira
le port 80 sur toutes les adresses IP que le serveur possède et essaiera ensuite
d'ouvrir le port 80 sur l'adresse IP 10.0.0.15, ce qui n'est pas possible
puisque ce port est déjà ouvert.
La configuration recommandée est de n'avoir qu'une seule ligne Listen 80
(c'est la valeur par défaut de httpd.conf) afin d'ouvrir par défaut le
port HTTP standard sur toutes les adresses IP, puis de rajouter une ligne
Listen supplémentaire pour chaque VirtualHost SSL en spécifiant
l'adresse IP (par exemple : Listen 10.0.0.15:443).
7.
Après la mise à jour vers apache-2.0.54-r13, le vhost par défaut (SSL ou
non-SSL) ne fonctionne plus
À partir de la version apache-2.0.54-r13, deux nouvelles directives ont été
ajoutées pour fixer le bogue 100624.
Les nouvelles directives en question sont : -D DEFAULT_VHOST pour
activer le vhost par défaut et -D SSL_DEFAULT_VHOST pour activer le vhost
SSL par défaut. Ces deux directives doivent être ajoutées à la variable
APACHE2_OPTS du fichier /etc/conf.d/apache2 pour être
activées (ce qui rétablit l'ancien comportement d'Apache).
8.
À l'aide...
Si aucune de ces astuces n'a pu résoudre votre problème ou si vous avez d'autres
questions, passez nous voir sur IRC dans le canal #gentoo-apache
(on y parle anglais) sur le serveur irc.freenode.net. Vous pouvez
aussi remplir un ticket de bogue sur le Bugzilla de Gentoo.
Ce document est protégé par la licence Creative
Commons : Paternité - Partage des Conditions Initiales à
l'Identique 2.5.
|