Aufgabe 07 - Dienst kaputt: Fehlersuche mit journalctl

Worum geht es?

Sie machen einen Dienst absichtlich kaputt und finden den Fehler in der Reihenfolge, die dieses Jahr trägt: Status ansehen, Log lesen, Konfiguration prüfen, und erst danach etwas ändern (siehe Kapitel Server aufsetzen und härten). Wer diese Reihenfolge umdreht, ändert im Dunkeln und weiß am Ende nicht, welche der fünf Änderungen geholfen hat.

Was Sie dafür brauchen

Kapitel Server aufsetzen und härten, Abschnitte Dienste mit systemd und Logs lesen.
Ihren Server aus den Aufgaben 04 bis 06.
Einen installierten Dienst zum Kaputtmachen. nginx genügt und ist mit sudo apt install nginx schnell eingerichtet.

Welche Kompetenzen Sie erwerben und zeigen

Sie steuern Dienste mit systemctl und unterscheiden start, enable, restart und reload nach ihrer Wirkung.
Sie grenzen ein Dienstproblem in der Reihenfolge Status, Log, Konfiguration ein und belegen jeden Schritt mit einer Ausgabe.
Sie schreiben eine Fehlersuche so auf, dass eine andere Person sie nachvollziehen kann.

Pädagogische Einordnung

Reproduktion: Dienste steuern und den Status ablesen (Teil A).
Reorganisation und Transfer: das Journal gezielt abfragen und eine Logzeile wiederfinden (Teil B).
Reflexion, Problemlösung und Urteilsbildung: selbst erzeugte Fehler eingrenzen und eine Vorgehensweise ableiten (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Dienste steuern

Rufen Sie systemctl status nginx auf. Notieren Sie fünf Angaben aus der Ausgabe: ob der Dienst läuft, seit wann, unter welcher Kennung, welche Datei ihn beschreibt, und was in den letzten Logzeilen steht.
Stoppen und starten Sie den Dienst. Rufen Sie nach jedem Schritt den Status auf und notieren Sie, welches Wort in der Zeile Active: steht.
Ermitteln Sie mit systemctl is-enabled nginx, ob der Dienst beim Hochfahren mitstartet. Erklären Sie in zwei Sätzen den Unterschied zwischen start und enable.
Erklären Sie in drei bis vier Sätzen den Unterschied zwischen restart und reload. Beschreiben Sie dabei einen Fall aus Ihrem späteren Projektbetrieb, in dem ein Benutzer diesen Unterschied bemerkt.
Im Kapitel steht ein Zustandsdiagramm mit den Zuständen inactive, activating, active, reloading und failed. Schreiben Sie zu jedem Übergang den Befehl oder das Ereignis auf, das ihn auslöst.

Teil B - Das Journal abfragen

Setzen Sie die vier Aufrufe des Kapitels ab und schreiben Sie zu jedem in einem Satz, für welche Frage er der richtige ist:
Terminal-Fenster
```
journalctl -u nginx
journalctl -u nginx -n 100
journalctl -u nginx -f
journalctl -p err --since today
```
Suchen Sie im Journal den Neustart aus Teil A Punkt 2 wieder. Notieren Sie die Logzeile mit Zeitstempel.
Ermitteln Sie, wie viele Fehlermeldungen Ihr System seit dem letzten Systemstart erzeugt hat. Sehen Sie sich drei davon an und beschreiben Sie eine in zwei Sätzen.
Erklären Sie in drei Sätzen, warum ein Fehler, der nicht ins Log geschrieben wird, auf einem Server praktisch nie stattgefunden hat. Beziehen Sie sich dabei auf den Unterschied zwischen Server und Arbeitsplatzrechner aus dem Kapitel.

Teil C - Selbst kaputt gemacht

Führen Sie die folgenden drei Störungen nacheinander durch. Zu jeder gehört derselbe Ablauf: Status ansehen, Log lesen, Konfiguration prüfen, dann beheben. Notieren Sie zu jedem dieser vier Schritte den Befehl und die Zeile der Ausgabe, die Sie weitergebracht hat.

Bauen Sie in die nginx-Konfiguration einen Syntaxfehler ein, etwa ein fehlendes Semikolon am Zeilenende, und versuchen Sie ein reload. Notieren Sie, woran Sie den Fehler erkennen und was sudo nginx -t dazu ausgibt.
Sorgen Sie dafür, dass ein anderer Prozess den Port belegt, auf dem nginx lauschen soll. Starten Sie den Dienst und ermitteln Sie mit ss -tulpn, welcher Prozess im Weg steht.
Verweisen Sie in der Konfiguration auf ein Verzeichnis, das entweder nicht existiert oder für die Kennung des Dienstes nicht lesbar ist. Grenzen Sie mit den Schritten aus Aufgabe 06 ein, welcher der beiden Fälle vorliegt.
Beantworten Sie nach allen drei Störungen in vier bis fünf Sätzen: Welche der drei war schon am Status erkennbar, welche erst im Log, welche erst in der Konfiguration? Leiten Sie daraus ab, warum die Reihenfolge Status, Log, Konfiguration und nicht die umgekehrte gilt.
Gewöhnen Sie sich die Prüfung vor der Übernahme an und setzen Sie sudo nginx -t && sudo systemctl reload nginx ab. Erklären Sie in zwei Sätzen, was das && an dieser Stelle verhindert.
Schreiben Sie aus Ihren Erfahrungen eine Checkliste zur Dienstdiagnose. Sie besteht aus sechs bis acht Schritten in der Reihenfolge, in der Sie sie das restliche Jahr abarbeiten wollen, und jeder Schritt nennt einen konkreten Befehl. Legen Sie die Checkliste in docs/betrieb.md ab.
Im nächsten Kapitel läuft Ihre Anwendung in einem Container statt als systemd-Dienst. Nennen Sie zwei Schritte Ihrer Checkliste, die dort nicht mehr funktionieren, und schreiben Sie zu jedem, welcher Befehl an seine Stelle tritt.

Wissenscheck

In welcher Reihenfolge gehen Sie vor, wenn ein Dienst nicht startet, und warum genau in dieser?
Was unterscheidet systemctl restart von systemctl reload, und wann ist der Unterschied für Benutzer spürbar?
Was unterscheidet start von enable?
Womit sehen Sie die letzten 100 Zeilen eines Dienstes, und womit verfolgen Sie sie laufend mit?
Wozu dient nginx -t bzw. sshd -t, und was bewirkt das && in nginx -t && systemctl reload nginx?
Warum steht bei einem Dienst im Zustand failed die wichtigste Information oft in der letzten Zeile vor dem Abbruch?
Warum lohnt es sich, bei einer Fehlersuche auch die Sackgassen aufzuschreiben?

Abgabe

Eine Datei protokoll.md mit den Teilen A bis C. Zu jeder der drei Störungen aus Teil C stehen darin die vier Schritte mit Befehl und entscheidender Ausgabezeile sowie die Behebung. Die Checkliste zur Dienstdiagnose und die Eingriffe dieser Übung stehen in docs/betrieb.md.