Sur tout Linux moderne, un service qui refuse de démarrer a déjà écrit exactement pourquoi. C'est dans le journal, et si les gens disent qu'il n'y a rien dans les logs, c'est qu'ils ont lancé journalctl sans argument et ont renoncé devant la masse.

Les cinq qui font le travail

journalctl -u nginx -n 50 --no-pager   # the last 50 lines for one unit
journalctl -u nginx -f                # follow it live
journalctl -u nginx --since "10 min ago"
journalctl -p err -b                  # errors only, this boot
journalctl -b -1                      # the boot BEFORE this one
-b -1 est celle vers laquelle tendre la main après un redémarrage inexpliqué : elle montre ce que disait la machine juste avant de tomber, ce que le démarrage actuel ne contient pas.

Quand un service refuse de démarrer

systemctl status app --no-pager -l
journalctl -u app -n 100 --no-pager

status montre le code de sortie et les dernières lignes ; le journal montre le reste. Une unité qui échoue immédiatement, c'est presque toujours un chemin, une permission ou un port déjà occupé - et les trois le disent en clair.

Le journal sur le disque

Par défaut il peut être volatil : gardé en mémoire et perdu au redémarrage, c'est-à-dire précisément quand vous en avez besoin. Rendez-le persistant.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

L'empêcher de remplir le disque

# /etc/systemd/journald.conf
SystemMaxUse=500M
MaxRetentionSec=1month
Une application qui écrit son propre fichier - les journaux d'accès de Nginx, les journaux lents de PHP-FPM - n'est pas dans le journal. Ceux-là sont dans /var/log et tournent séparément ; voyez la rotation des journaux.