Auf jedem modernen Linux hat ein Dienst, der nicht startet, längst genau aufgeschrieben, warum. Es steht im Journal, und der Grund, warum Leute sagen, in den Logs stehe nichts, ist: Sie haben journalctl ohne Argumente aufgerufen und angesichts der Menge aufgegeben.

Die fünf, die die Arbeit machen

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 ist das, wonach Sie nach einem unerklärten Neustart greifen: Es zeigt, was die Maschine kurz vor dem Ausfall gesagt hat - und das steht im aktuellen Bootvorgang nicht.

Wenn ein Dienst nicht starten will

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

status zeigt den Exit-Code und die letzten paar Zeilen; das Journal zeigt den Rest. Eine Unit, die sofort scheitert, ist fast immer ein Pfad, ein Recht oder ein bereits belegter Port - und alle drei sagen das in klaren Worten.

Das Journal auf der Platte

Standardmäßig kann es flüchtig sein - im Speicher gehalten und beim Neustart verloren, also genau dann, wenn Sie es brauchen. Machen Sie es dauerhaft.

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

Verhindern, dass es die Platte füllt

# /etc/systemd/journald.conf
SystemMaxUse=500M
MaxRetentionSec=1month
Eine Anwendung, die ihre eigene Datei schreibt - Nginx-Zugriffslogs, PHP-FPM-Slow-Logs -, steht nicht im Journal. Die liegen in /var/log und werden getrennt rotiert; siehe Logrotation.