Gentoo Logo

Résolution des problèmes avec Apache

Table des matières :

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

(Faites tout ceci dans l'ordre, c'est très important !)

(D'abord, on supprime l'Apache actuel.)
# emerge -aCv '=www-servers/apache-2*'

(Ensuite, on recompile les outils.)
# emerge -av '=dev-libs/apr-0*' '=dev-libs/apr-util-0*'

(Enfin, on recompile Apache.)
# emerge -av '=www-servers/apache-2*'

(Trouvons maintenant quels paquets dépendent d'Apache.)
$ 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

(Et recompilons tous les modules que nous avions installés.)
# 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

(Dans /etc/conf.d/apache2,)

(avant...)
APACHE2_OPTS="-D PHP5 -D USERDIR -D SSL"

(après.)
APACHE2_OPTS=""

Exemple de code 3.3 : Redémarrer Apache

# /etc/init.d/apache2 stop
(Vérifiez qu'Apache est bien arrêté.)
# 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

(Avant...)
CFLAGS="-O2 -mcpu=pentium3 -march=pentium3  -pipe"

(après. Notez la suppression de l'espace.)
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

(Placez-vous dans le répertoire de configuration d'Apache...)
# cd /etc/apache2/

(et listez les directives Listen.)
# 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.



Imprimer

Dernière mise à jour le 29 novembre 2007

Résumé : Ce document décrit un certain nombre de moyens de trouver ce qui ne va pas dans une installation Apache qui fonctionne mal.

Michael Stewart
Auteur

Elfyn McBratney
Contributor

Bryan Østergaard
Contributor

Benedikt Böhm
Contributor

Camille Huot
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.