Consulter les journaux Linux et diagnostiquer un service qui ne démarre pas

Pour consulter les journaux Linux et trouver pourquoi un service ne démarre pas, commencez par vérifier son état avec systemctl status, puis lisez ses messages avec journalctl -u. Cette méthode permet d’isoler une erreur de configuration, de permission, de port occupé ou de dépendance avant de modifier quoi que ce soit.

Les journaux Linux sont les traces enregistrées par le système et les applications pour décrire un événement, une erreur ou un changement d’état. Le parcours ci-dessous suit une logique simple : identifier le service, examiner les messages récents, filtrer les erreurs utiles, corriger la cause probable et confirmer que le service répond réellement.

Prérequis avant de diagnostiquer un service Linux

Le tutoriel suppose une distribution utilisant systemd, comme Debian, Ubuntu, Fedora, RHEL ou de nombreuses distributions dérivées. systemd est le gestionnaire de services qui lance des unités telles qu’un serveur web, une base de données ou un service réseau ; journalctl est l’outil qui interroge les journaux structurés collectés par systemd-journald.

Préparez le nom du service concerné et un accès au terminal. Les commandes de lecture sont généralement sans risque, tandis que les redémarrages et les modifications de configuration demandent une attention particulière. Selon la configuration locale, la lecture complète des journaux peut exiger sudo ou l’appartenance au groupe systemd-journal.

• Un terminal ouvert sur la machine concernée, en local ou via SSH.
• Le nom présumé du service, par exemple nginx.service, apache2.service ou ssh.service.
• Les droits administrateur seulement si vous devez redémarrer un service ou modifier sa configuration.
• Une copie du fichier de configuration avant toute modification manuelle.

Un journal utile ne se lit pas comme un roman : il se filtre jusqu’à relier un message précis à l’action qui a échoué.

Comment vérifier rapidement l’état d’un service Linux ?

Pour vérifier l’état d’un service Linux, exécutez systemctl status nom.service. La commande indique si le service est actif, en échec ou inactif, affiche son processus principal et reprend plusieurs messages récents. Le résultat donne un premier point de départ, mais il ne remplace pas la lecture des journaux complets.

Étape 1 : identifier le nom exact du service

Commencez par employer le nom fourni par la documentation du logiciel ou par la sortie de votre outil d’installation. Si le nom est déjà connu, ajoutez l’extension .service pour rendre la commande explicite. Un mauvais nom d’unité produit un diagnostic trompeur, car systemd cherchera un service qui n’existe pas.

systemctl status nginx.service

Le résultat attendu contient une ligne commençant par Active:. Un état failed confirme que systemd a lancé le service puis a constaté un échec ; un état inactive signifie seulement que le service ne tourne pas au moment de la vérification.

Étape 2 : lire les informations affichées par systemctl

Repérez d’abord la date de l’échec, le code de sortie et les dernières lignes affichées. Un message comme « permission denied », « address already in use » ou « no such file or directory » oriente le diagnostic vers une famille de causes, sans démontrer à lui seul quelle ligne de configuration doit être corrigée.

systemctl status nginx.service --no-pager

La présence de --no-pager évite l’ouverture d’un lecteur interactif et facilite la copie des messages dans un ticket ou une note technique. Conservez le premier message d’erreur chronologiquement pertinent : les erreurs suivantes sont souvent des conséquences.

Étape 3 : vérifier l’activation au démarrage

Un service peut fonctionner lorsqu’il est lancé manuellement sans être configuré pour démarrer au prochain redémarrage. Vérifiez ce point après avoir traité la panne immédiate, car l’activation au démarrage n’explique pas un échec de lancement dû à une configuration invalide.

systemctl is-enabled nginx.service

La réponse attendue est généralement enabled lorsque le service doit démarrer automatiquement. Une réponse différente décrit la politique de démarrage de l’unité, pas la disponibilité réelle de l’application.

Comment consulter les journaux Linux avec journalctl ?

Pour consulter les journaux Linux associés à un service systemd, utilisez journalctl -u nom.service. Cette commande cible l’unité demandée, puis peut être combinée avec un filtre de démarrage, de date, de gravité ou un suivi en direct. Elle évite de parcourir l’ensemble des événements de la machine.

La commande journalctl lit la base binaire structurée de systemd-journald. Les fichiers classiques de /var/log/ restent utiles pour certaines applications et pour rsyslog, mais le journal systemd est souvent le chemin le plus direct pour diagnostiquer un service systemd qui ne démarre pas.

Étape 4 : afficher les messages du démarrage en cours

Ajoutez -b pour limiter la recherche au démarrage actuel. Ce filtre réduit le bruit produit par les incidents anciens et rend plus lisible la relation entre un redémarrage du service et ses messages récents.

sudo journalctl -u nginx.service -b --no-pager

Le résultat attendu est une chronologie de messages associés à l’unité nginx.service. Si le service a été relancé plusieurs fois, lisez les premières lignes qui précèdent l’échec le plus récent plutôt que de vous limiter à la dernière ligne affichée.

Étape 5 : suivre les journaux pendant une tentative de démarrage

Ouvrez un premier terminal pour suivre les messages, puis utilisez un second terminal pour lancer ou redémarrer le service. Cette observation en temps réel est particulièrement utile lorsqu’une application échoue immédiatement et qu’un message n’apparaît qu’au moment précis du lancement.

1. Dans le premier terminal, lancez la commande de suivi.
2. Dans le second terminal, démarrez ou redémarrez le service concerné.
3. Revenez au premier terminal et relevez les messages produits pendant cette action.

sudo journalctl -u nginx.service -f

sudo systemctl restart nginx.service

Le résultat attendu est l’apparition de nouveaux messages au fil de l’eau. Arrêtez le suivi avec Ctrl+C après avoir relevé l’erreur utile ; la commande de suivi ne modifie pas le service.

Étape 6 : filtrer par période, priorité ou démarrage précédent

Les filtres réduisent le volume de messages et améliorent la qualité du diagnostic. Un filtre temporel sert à examiner une plage précise, tandis que le filtre de priorité fait ressortir les erreurs et les événements plus graves.

Objectif	Commande	Usage et limite
Voir les erreurs d’un service	sudo journalctl -u nginx.service -p err -b	Réduit le bruit, mais peut masquer un avertissement annonçant la cause.
Examiner une période	sudo journalctl -u nginx.service --since "2026-07-13 09:00"	Adaptez la date et l’heure à l’incident réellement observé.
Lire le dernier démarrage	sudo journalctl -u nginx.service -b	Utile après un redémarrage récent de la machine.
Lire un démarrage précédent	sudo journalctl -u nginx.service -b -1	Requiert que les journaux de ce démarrage soient encore disponibles.

Pour approfondir le fonctionnement général d’une distribution orientée poste de travail, le guide sur l’utilisation de Manjaro Linux apporte des repères complémentaires sur l’environnement Linux. Les noms de services, les chemins de journaux et les paquets installés peuvent toutefois varier d’une distribution à l’autre.

Comprendre les erreurs les plus fréquentes dans les journaux

Les messages d’un service Linux en échec décrivent souvent une condition technique vérifiable : fichier absent, autorisation refusée, port déjà occupé, option inconnue ou dépendance indisponible. Une erreur doit être lue avec son contexte, car le même code de sortie peut recouvrir des causes différentes selon l’application.

Erreur de configuration

Une erreur de syntaxe ou une directive non reconnue apparaît fréquemment juste après le chargement du fichier de configuration. Recherchez le nom du fichier, le numéro de ligne si l’application le fournit, puis consultez la documentation officielle du logiciel concerné avant de corriger la directive.

Permission refusée

Un message de permission indique que le compte utilisé par le service ne peut pas lire, écrire ou traverser un chemin nécessaire. Vérifiez le propriétaire, les permissions et le chemin complet du fichier ou du répertoire ; évitez de résoudre le problème en lançant durablement le service avec des privilèges excessifs.

Port déjà utilisé

Un port déjà utilisé signifie qu’un autre processus écoute probablement sur l’adresse et le port demandés. Le journal identifie parfois le port concerné, mais la résolution dépend ensuite du logiciel qui doit légitimement l’utiliser et de la configuration réseau locale.

Dépendance, fichier ou répertoire indisponible

Une application peut dépendre d’un fichier de configuration, d’un répertoire de données, d’un montage ou d’un autre service. Vérifiez d’abord que la ressource indiquée existe et que son chemin correspond à la configuration ; un redémarrage répété ne recrée pas automatiquement une dépendance manquante.

Le redémarrage confirme une hypothèse ; il ne remplace pas l’identification de la cause dans les journaux.

Comment corriger un service avant de le redémarrer ?

Avant de redémarrer un service Linux, sauvegardez le fichier modifié, vérifiez la syntaxe avec l’outil prévu par l’application et relisez les dépendances signalées dans les journaux. Un redémarrage immédiat sans contrôle peut effacer le contexte opérationnel et multiplier les messages secondaires.

Étape 7 : sauvegarder le fichier avant modification

Copiez le fichier de configuration dans un emplacement identifiable avant toute modification. Utilisez un nom incluant la date ou un suffixe explicite, puis modifiez uniquement la directive liée à l’erreur observée. Cette précaution rend un retour arrière possible si la correction aggrave la panne.

sudo cp /chemin/vers/configuration.conf /chemin/vers/configuration.conf.sauvegarde

Remplacez le chemin d’exemple par celui affiché dans le journal ou dans la documentation du logiciel. Le résultat attendu est une copie distincte du fichier, pas l’écrasement de la configuration d’origine.

Étape 8 : valider la configuration avec l’outil du logiciel

Les commandes de validation diffèrent selon le serveur web, la base de données ou le démon concerné. Consultez la documentation officielle de l’application pour connaître sa commande de test, car systemd contrôle le lancement de l’unité mais ne peut pas valider universellement la syntaxe interne de chaque logiciel.

Une validation réussie ne garantit pas que le service sera accessible sur le réseau. Elle confirme seulement que l’application accepte la configuration vérifiée dans son contexte de test.

Étape 9 : redémarrer, puis relire immédiatement l’état

Redémarrez le service seulement après la correction et la validation disponibles. Relancez ensuite systemctl status et le filtre journalctl du démarrage en cours afin de vérifier que l’ancien message d’échec ne réapparaît pas.

sudo systemctl restart nginx.service
systemctl status nginx.service --no-pager
sudo journalctl -u nginx.service -b -p err --no-pager

Le résultat attendu est un état active (running) et l’absence de nouvelle erreur pertinente dans les messages récents. Un état actif ne suffit pas pour un service exposé : testez aussi la fonction réelle attendue, comme une connexion, une page web ou une requête applicative.

Consulter les fichiers de journaux Linux dans /var/log/

Les fichiers de journaux Linux stockés dans /var/log/ complètent journalctl, notamment lorsque rsyslog écrit des messages en texte clair ou lorsqu’une application possède ses propres fichiers. rsyslog est un service de journalisation qui peut traiter des messages syslog et les distribuer selon des règles définies dans /etc/rsyslog.conf.

Repérer un journal applicatif et suivre ses nouvelles lignes

Le chemin exact dépend de l’application et de la distribution. Consultez la documentation du logiciel ou la configuration locale, puis utilisez tail -f sur le fichier identifié pour observer les lignes ajoutées pendant une nouvelle tentative de démarrage.

sudo tail -f /var/log/syslog

Sur certains systèmes, le fichier global peut porter un autre nom ou ne pas contenir les messages attendus. Le bon fichier est celui configuré et alimenté par votre service, non celui qui paraît le plus familier.

Rechercher une erreur dans un fichier volumineux

Utilisez une recherche textuelle pour faire ressortir un terme vu dans systemctl status, comme le nom du service, « error » ou « failed ». Gardez à l’esprit que le texte des messages dépend du logiciel et peut être localisé différemment.

sudo grep -i "error" /var/log/syslog

Les fichiers classiques sont souvent gérés par un mécanisme de rotation tel que logrotate. Ne supprimez pas un fichier de journal en cours d’utilisation pour « faire de la place » : vous pourriez compliquer le suivi de l’incident ou perturber les attentes d’un processus qui écrit encore dedans.

Comparer journalctl, rsyslog et les fichiers classiques

journalctl, rsyslog et les fichiers de /var/log/ ne répondent pas exactement au même besoin. Le premier interroge les données de systemd-journald ; rsyslog traite des messages syslog ; les fichiers texte servent à lire ou archiver certains flux, selon la configuration de la machine.

Outil ou emplacement	À privilégier pour	Point de vigilance
journalctl	Diagnostiquer une unité systemd par service, période ou priorité.	Les journaux peuvent être volatils si la persistance n’est pas configurée.
/var/log/	Lire des journaux texte syslog ou propres à une application.	Les noms et emplacements varient selon la distribution et le logiciel.
rsyslog	Router ou enregistrer des messages syslog selon des règles locales.	La configuration doit être vérifiée dans /etc/rsyslog.conf et ses inclusions éventuelles.

La persistance de journald peut être configurée dans /etc/systemd/journald.conf, notamment avec Storage=persistent. La documentation officielle de systemd précise que la présence de /var/log/journal/ permet aussi de conserver les journaux entre les redémarrages ; vérifiez l’effet réel sur votre machine avant de modifier cette configuration.

Erreurs fréquentes lors du dépannage d’un serveur Linux

Les erreurs de diagnostic viennent souvent d’une lecture trop rapide des messages ou d’une modification faite avant d’avoir identifié le composant concerné. Les pièges suivants ralentissent la recherche et peuvent rendre le retour arrière plus difficile.

• Lire seulement la dernière ligne : recherchez le premier échec dans la séquence, car les lignes finales décrivent souvent l’arrêt du service plutôt que son origine.
• Redémarrer sans suivre les journaux : lancez journalctl -f dans un autre terminal pour associer chaque nouveau message à l’action de redémarrage.
• Modifier plusieurs paramètres à la fois : changez une hypothèse vérifiable, puis testez ; plusieurs changements empêchent de savoir lequel a eu un effet.
• Confondre service actif et service fonctionnel : un état actif ne prouve pas qu’un port répond, qu’une base de données accepte une connexion ou qu’une application sert ses utilisateurs.
• Nettoyer les journaux pendant l’incident : conservez les messages jusqu’à la résolution et, si nécessaire, archivez les extraits utiles dans un emplacement sécurisé.

Bonnes pratiques pour garder des journaux exploitables

Les journaux servent au diagnostic, à la maintenance et à la surveillance de la sécurité. Une conservation adaptée dépend de l’espace disque disponible, des contraintes de l’organisation et de la sensibilité des données enregistrées ; les journaux peuvent contenir des identifiants techniques, des adresses ou des éléments utiles à une investigation.

Vérifiez régulièrement la taille occupée par le journal systemd avant d’envisager un nettoyage. La commande journalctl --disk-usage permet d’observer l’espace utilisé ; les options --vacuum-size, --vacuum-time et --vacuum-files servent à réduire les archives selon un critère choisi. Un nettoyage doit répondre à une contrainte identifiée, jamais remplacer une politique de conservation.

Lorsqu’un nettoyage est réellement nécessaire, la documentation de journalctl indique par exemple qu’une commande telle que sudo journalctl --vacuum-size=200M réduit les archives pour viser une taille de 200 Mo. Cette valeur est un exemple technique, pas une taille recommandée universellement : vérifiez la capacité du disque, les obligations de conservation et les journaux encore utiles à l’analyse.

Pour les environnements où l’intégrité des traces est importante, systemd-journald propose également le paramètre Seal=yes dans /etc/systemd/journald.conf. Cette option vise à aider à détecter une altération des fichiers journaux ; elle ne remplace ni les sauvegardes ni le contrôle des accès.

Sources utiles à consulter

La documentation officielle reste le bon repère lorsque les options diffèrent selon la version de systemd ou la distribution. Les pages suivantes décrivent les commandes et fichiers mentionnés dans ce tutoriel.

• Documentation officielle de journalctl : filtres par unité, date, priorité, démarrage et gestion de l’espace disque.
• Documentation officielle de systemctl : état, démarrage, redémarrage et activation des unités systemd.
• Référence journald.conf : persistance, stockage et paramètres de systemd-journald.
• Documentation de configuration rsyslog : règles de journalisation et destinations des messages syslog.

Questions fréquentes sur les journaux Linux

Quelle commande affiche les dernières erreurs d’un service Linux ?

La commande sudo journalctl -u nom.service -p err -b affiche les erreurs du service pour le démarrage actuel. Retirez -p err si vous devez aussi lire les avertissements ou les messages d’information qui précèdent l’échec.

Comment suivre les journaux pendant le redémarrage d’un service ?

Lancez sudo journalctl -u nom.service -f dans un terminal, puis redémarrez le service dans un autre avec sudo systemctl restart nom.service. Les nouveaux messages s’affichent au moment où systemd tente de lancer l’unité.

Pourquoi un service est-il actif mais inaccessible ?

Un état active (running) confirme que le processus est lancé, pas que le service répond à son usage attendu. Vérifiez ensuite l’écoute réseau, la configuration applicative, les dépendances externes et le test fonctionnel adapté au logiciel.

Où chercher si journalctl ne renvoie aucun message utile ?

Vérifiez le nom exact de l’unité, la période filtrée et les droits de lecture. Consultez aussi les fichiers dans /var/log/ ainsi que les journaux propres à l’application, car tous les logiciels n’écrivent pas leurs messages au même endroit.

Peut-on supprimer les anciens journaux Linux ?

La suppression manuelle de fichiers actifs est à éviter. Pour systemd-journald, utilisez plutôt les mécanismes prévus comme journalctl --vacuum-size, après avoir vérifié l’espace disque et conservé les traces nécessaires au diagnostic ou à la conformité.