Lire les logs

Inroduction

Les logs sont des fichiers textes dans lesquels les divers programmes du serveur inscrivent tout ce qu'ils font. Il s'agit d'un journal de bord précis, fiable et très utile en cas de bug incompréhensible. Les logs se trouvent dans le répertoite /var/log.

Exemple :

r10013:~# ls /var/log
acpid daemon.log dmesg.2.gz kern.log mail.log syslog wtmp
aptitude debug dmesg.3.gz lastlog mail.warn syslog.0
auth.log dmesg dpkg.log lpr.log messages syslog.1.gz
boot dmesg.0 faillog mail.err news user.log
btmp dmesg.1.gz fsck mail.info pycentral.log uucp.log

On constate qu'il y a plusieurs logs : un log par processus. Les logs importants sont : syslog, daemon.log, auth.log et messages.

- syslog : logs généraux du système (syslogd est le démon qui se charge de faire les logs)

- daemon.log : logs des démons (programmes s'exécutant en tâche de fond)

- messages : les différents messages envoyés par le noyau

NB : on peut également trouver des fichiers type messages.1.gz : il s'agit d'archives crées par un programme chargé de faire tourner les logs (logrotate) afin de ne pas se retrouver avec un seul fichier de plusieurs gigas.

NB2 : auth.log est aussi un log important car il journalise les connections effectuées par les utilisateurs du système (root, cron, etc..).

Connaître la date et la nature du bug

Avant d'aller voir les logs, il faut connaitre la date et l'heure +ou- précise à laquelle s'est produit l'erreur. Si on ne sait plus, il suffit de repoduire l'erreur et de noter l'heure. La nature de l'erreur est aussi important : on n'ira en général pas chercher dans le kernel.log pour une erreur Apache "Internal Server Error".

Trouver le bon log

Quand on est en face d'un bug, il faut d'abord trouver le log dans lequel on va chercher. Il faut voir si le programme bugué possède son propre log : en général, le nom du log est similaire au nom du programme (parfois il y a même un dossier comme avec Apache : /var/log/apache2/). Il faut également scruter dans les 3 logs principaux décrits plus haut. Si le programme n'a pas son propre log, on ira voir dans les 3 du dessus. Noter que les logs d'Apache peuvent se trouver ailleurs que dans le /var/log. Pour trouver l'emplacement, il suffit de regardez dans le VirtualHost. En général, ils sont dans le dossier "logs" qui se trouve au même endroit que le dossier "www" contenant le site web en cause.

Pour les logs Apache : error.log journalise les erreurs ( fichier inexistant, etc...) tandis que access.log journalise les requêtes (téléchargement de telle page web).

Chercher dans le log

Une fois qu'on a la date et l'heure et l'ensemble des logs susceptibles de contenir la czuse du bug, on procède comme dans cet exemple.

1) l'erreur est "Internal Server Error" et s'est produite le 26/02/2008 à 11h56 en chargeant une page

2) on se place dans le répertoire de logs du site web : cd /home/real-private-server.com/logs/

3) on regarde un peu ce qu'on a :commande ls qui renvoie "access.log error.log"

4) on jette un oeil à error.log : tail -10 error.log

[Tue Feb 26 11:54:32 2008] [alert] [client 83.XXX.XX.XX] /home/real-private-server.com/www/.htaccess: allow and deny must be followed by 'from'

5) la date et l'heure semble correspondre: le message indique une erreur dans le .htaccess

Si on ne trouve pas tout de suite :

1) on comprend la synthaxe : [Tue Feb 26 11:54:32 2008]

2) on trie en affichant les erreurs survenues le 26 vers 11h50 : cat error.log | grep "Tue Feb 26 11:5" et bingo :

[Tue Feb 26 11:54:32 2008] [alert] [client 83.182.34.83] /home/real-private-server.com/www/.htaccess: allow and deny must be followed by 'from'

Correction du bug

Maintenant qu'on sait d'où vient l'erreur, on peut la corriger. Dans notre exemple, le fichier .htaccess contenait ceci :

Deny not from all

Il s'agissait bien évidemment d'une erreur de synthaxe, il fallait écrire : Deny from all.

Commentaires

L'exemple choisit est volontairement simple pour mettre en évidence la façon de répérer la partie du log qui nous intéresse. Souvent, la description de l'erreur est encore plus complète que ça : le log indique quelle ligne ou quelle directive d'un certain fichier coince. Il peut aussi s'agit d'un problème de droits du fichier.