Tail sous Linux : suivre un log en direct sans relancer la commande toutes les dix secondes

Quand un service Linux ne répond plus ou qu’une application se met à générer des erreurs, relancer la même commande toutes les dix secondes devient vite pénible. C’est exactement le genre de cas où tail rend service : vous affichez les dernières lignes d’un fichier, puis vous pouvez suivre ce qui arrive en direct.

Je l’utilise surtout pour vérifier un log pendant un redémarrage de service, une connexion SSH, une erreur Nginx ou un script qui écrit dans un fichier. Ce n’est pas un outil magique de diagnostic, mais c’est souvent le moyen le plus rapide de voir si quelque chose bouge vraiment.

À quoi sert tail sous Linux ?

La commande tail affiche la fin d’un fichier. Sans option, elle montre les dix dernières lignes :

tail /var/log/syslog

Sur Debian ou Ubuntu, selon votre configuration, vous pouvez aussi tomber sur des fichiers comme /var/log/auth.log, /var/log/nginx/error.log ou les logs d’une application placés dans /var/log/nom-du-service/.

Premier réflexe avant d’aller plus loin : vérifiez que le fichier existe et que vous avez le droit de le lire.

ls -lh /var/log/syslog
sudo tail /var/log/syslog

Si la commande ne renvoie rien, ce n’est pas forcément une panne. Le fichier peut être vide, absent sur votre distribution, ou remplacé par le journal systemd.

Afficher plus ou moins de lignes avec tail -n

Par défaut, dix lignes suffisent rarement quand vous essayez de comprendre une erreur. Avec -n, vous choisissez le nombre de lignes à afficher :

tail -n 50 /var/log/syslog
sudo tail -n 100 /var/log/nginx/error.log

Je vous conseille de commencer avec 50 ou 100 lignes. Si vous demandez 5000 lignes, vous perdez l’intérêt de tail et vous feriez parfois mieux d’ouvrir le fichier avec less ou de filtrer directement.

Pour un fichier très bavard, vous pouvez aussi combiner tail avec grep :

sudo tail -n 200 /var/log/syslog | grep -i "error"

Attention tout de même : filtrer trop tôt peut vous faire rater le message juste avant l’erreur. Quand je ne sais pas encore ce que je cherche, je lis d’abord les lignes brutes.

Suivre un log en direct avec tail -f

L’option la plus utile est -f. Elle garde la commande ouverte et affiche les nouvelles lignes dès qu’elles sont écrites dans le fichier :

sudo tail -f /var/log/syslog

Vous pouvez ensuite ouvrir un deuxième terminal, relancer votre service, refaire la connexion qui pose problème, ou reproduire l’erreur dans l’application. Les nouvelles lignes arrivent au fil de l’eau.

sudo systemctl restart nginx
sudo tail -f /var/log/nginx/error.log

Pour quitter le suivi, utilisez simplement Ctrl + C. Ne fermez pas votre session SSH à l’arrache si vous êtes connecté sur un serveur distant, surtout si vous êtes en train de corriger un service important.

Il existe aussi tail -F, avec un F majuscule. Cette option suit le nom du fichier et résiste mieux à une rotation de logs. C’est pratique quand le fichier peut être recréé par logrotate pendant votre diagnostic.

sudo tail -F /var/log/nginx/error.log

Filtrer pendant le suivi sans perdre le direct

Vous pouvez suivre un fichier et filtrer en même temps. Pour chercher une erreur précise :

sudo tail -f /var/log/syslog | grep --line-buffered -i "failed"

L’option --line-buffered évite que grep garde les lignes en attente trop longtemps. Sans elle, vous pouvez croire que rien ne se passe alors que le filtre bloque l’affichage.

Pour un diagnostic simple, je préfère souvent ouvrir deux terminaux : un avec le log complet, un autre avec le filtre. Ça évite de passer à côté d’un avertissement qui ne contient pas exactement le mot recherché.

Quand préférer journalctl à tail ?

Sur les distributions récentes avec systemd, beaucoup d’informations passent par journalctl. Si vous cherchez les logs d’un service systemd, journalctl est souvent plus propre que tail sur un fichier dans /var/log.

sudo journalctl -u ssh -n 50
sudo journalctl -u ssh -f

Avec -u, vous ciblez une unité systemd. Avec -n 50, vous affichez les 50 dernières lignes. Avec -f, vous suivez le journal en direct, comme avec tail.

Si vous redémarrez un service, vous pouvez donc combiner les deux approches :

sudo systemctl restart ssh
sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -f

J’ai tendance à utiliser tail quand je sais exactement quel fichier applicatif surveiller. Pour un service systemd, un boot ou une erreur de démarrage, je pars plutôt sur journalctl. Si vous voulez creuser ce point, l’article sur journalctl et les logs du dernier démarrage complète bien cette commande.

Les erreurs classiques avec tail

La première erreur, c’est de suivre le mauvais fichier. Avant de rester bloqué devant un log silencieux, vérifiez le service et les fichiers ouverts :

systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50
sudo ls -lh /var/log/nginx/

Deuxième erreur : oublier les droits. Sur un serveur, beaucoup de logs nécessitent sudo. Si vous avez un message Permission denied, ne changez pas les droits du fichier au hasard. Relancez plutôt la lecture avec sudo.

Troisième erreur : confondre absence de log et absence de problème. Une application peut écrire ailleurs, envoyer ses logs vers systemd, ou journaliser seulement certains niveaux d’erreur.

Pour vérifier plus largement l’état du serveur, vous pouvez aussi regarder les services en échec avec systemd :

systemctl --failed
systemctl list-jobs

Si le problème touche un port réseau ou un service qui n’écoute plus, l’article sur netstat, ss et les ports ouverts sous Linux peut aussi vous aider à vérifier ce qui est réellement exposé.

Une méthode simple pour diagnostiquer sans se disperser

Quand je dois vérifier un service qui vient de tomber, je garde une méthode courte :

• identifier le service ou le fichier de log concerné ;
• afficher les dernières lignes avec tail -n 50 ou journalctl -n 50 ;
• lancer le suivi avec tail -f, tail -F ou journalctl -f ;
• reproduire l’action qui pose problème ;
• noter l’heure et le message exact avant de modifier la configuration.

Ce dernier point évite de bricoler à l’aveugle. Un log lu au bon moment vaut mieux que trois redémarrages sans comprendre ce qui vient de se passer.

Pour la documentation de référence, vous pouvez consulter la page GNU Coreutils sur tail et la page systemd sur journalctl.

sudo apt update && sudo apt upgrade