Un service ne démarre pas ou une fonction échoue ? L’état et les journaux du bon moment aident avant qu’un redémarrage ne modifie les indices. Ce guide concerne systemd. example.service représente le service réellement concerné.
Étapes
- Notez heure, fuseau et fonction touchée. Trouvez le nom exact de l’unité dans la documentation ou avec
systemctl list-units --type=service --all. Les noms diffèrent selon la distribution. - Lisez
systemctl status example.service --no-pager --full. Distinguez Loaded, Active et erreurs précises. ‘enabled’ décrit l’activation au démarrage, pas la preuve du bon fonctionnement actuel. - Lisez
journalctl -u example.service -b -n 100 --no-pager. La sortie couvre le démarrage actuel et les 100 dernières entrées correspondantes. Pour un incident plus ancien, cela peut exclure les messages nécessaires. - Au besoin utilisez
journalctl -u example.service --since '2026-09-16 12:00:00' --until '2026-09-16 12:30:00' --no-pageren remplaçant les deux horaires. Vérifiez le fuseau du système. Lisez aussi les messages précédant immédiatement l’échec. - Pour un service utilisateur, utilisez
systemctl --user status example.serviceetjournalctl --user -u example.servicesous le compte concerné. Des entrées absentes peuvent aussi indiquer des droits insuffisants, d’autres fichiers de log ou une conservation expirée.
Vérifier le résultat
Notez la première erreur précise, son heure et l’état du service. Testez séparément la fonction réelle : ‘active’ ne prouve pas une connexion, requête ou opération réussie. Définissez un prochain test ciblé, pas une série de redémarrages arbitraires.
Annulation et limites
Ces commandes lisent sans modifier le service. Avant redémarrage, changement de configuration ou reset-failed, clarifiez conséquences et retour arrière. Les journaux peuvent contenir des données confidentielles ; ne partagez que les extraits nécessaires et nettoyés.