Einführung
Ein Prozess ist ein laufendes Programm. Ein Dienst ist eine langfristig ausgeführte Systemfunktion, die anhand einer Definition und einer Lebenszyklusregelung verwaltet wird. Unter Ubuntu liest systemd Unit-Definitionen ein, startet und beendet Dienste, verfolgt deren Zustände und protokolliert ihre Ausgaben im System-Journal.
In diesem Lab verwenden Sie den isolierten Übungsdienst labex-heartbeat. Sie untersuchen dessen Unit, steuern den Laufzeitstatus, konfigurieren die Aktivierung beim Systemstart, fragen Journal- und herkömmliche Textprotokolle ab, verfolgen laufende Ausgaben, diagnostizieren einen kontrollierten Fehler und stellen den ordnungsgemäßen Betrieb wieder her. Sie bearbeiten keine Unit-Dateien und greifen nicht auf den SSH-Dienst zu.
systemd und Service-Units erkennen
In diesem Schritt bestätigen Sie, dass systemd verfügbar ist, und unterscheiden laufende Units von installierten Unit-Dateien.
Wechseln Sie in den Arbeitsbereich des Labs:
cd /home/labex/project/service-lab
Zeigen Sie die Version von systemd an. Die erste Zeile reicht zur Identifikation aus:
systemctl --version | head -n 1
Fragen Sie den Gesamtzustand von systemd ab:
systemctl is-system-running || true
running bedeutet, dass alle erforderlichen Units fehlerfrei sind. Eine Trainings-VM kann degraded melden, wenn eine unabhängige optionale Unit fehlgeschlagen ist. Der Befehl zeigt dennoch, dass systemd antwortet.
Listen Sie eine Auswahl der aktuell laufenden Dienste auf:
systemctl list-units --type=service --state=running --no-pager | head -n 12
Eine Unit ist ein von systemd verwaltetes Objekt. Service-Units enden mit .service. Unit-Dateien beschreiben, was verwaltet werden kann, auch wenn es aktuell nicht läuft:
systemctl list-unit-files --type=service --no-pager | head -n 12
Speichern Sie eine kompakte Zusammenfassung von systemd. Die Befehlsersetzung $(...) fügt die Befehlsausgabe in den Text ein, den printf schreibt:
printf 'systemd=%s\nstate=%s\n' "$(systemctl --version | head -n 1)" "$(systemctl is-system-running)" > systemd-summary.txt
cat systemd-summary.txt
Eine Service-Definition und ihren Zustand untersuchen
In diesem Schritt untersuchen Sie den vorbereiteten Übungsdienst, bevor Sie ihn starten.
systemctl status kombiniert den Pfad der geladenen Unit, den Aktivierungsstatus, den Laufzeitstatus, Informationen zum Prozess und die neuesten Protokollzeilen:
cd /home/labex/project/service-lab
systemctl status labex-heartbeat.service --no-pager
Der Dienst sollte inactive (dead) und disabled sein. inactive bedeutet, dass er derzeit nicht läuft. disabled bedeutet, dass er nicht so konfiguriert ist, dass er beim Systemstart über sein Installationsziel gestartet wird. Dies sind zwei voneinander unabhängige Eigenschaften.
Zeigen Sie die Unit-Definition an:
systemctl cat labex-heartbeat.service
Der Abschnitt [Unit] beschreibt Identität und Reihenfolge, [Service] definiert den Prozess und [Install] beschreibt die Aktivierung. Sie untersuchen nur diese vorbereitete Unit und müssen keine eigene Unit schreiben.
Verwenden Sie systemctl show für maschinenlesbare Eigenschaften:
systemctl show labex-heartbeat.service -p LoadState -p ActiveState -p SubState -p UnitFileState
Speichern Sie diese Eigenschaften zur Überprüfung:
systemctl show labex-heartbeat.service -p LoadState -p ActiveState -p SubState -p UnitFileState > service-properties.txt
cat service-properties.txt
Einen Dienst starten, stoppen und neu starten
In diesem Schritt ändern Sie den Laufzeitstatus des Übungsdienstes und überprüfen jedes Ergebnis.
Zum Starten und Stoppen von Systemdiensten sind erhöhte Berechtigungen erforderlich. Starten Sie den Dienst:
sudo systemctl start labex-heartbeat.service
Prüfen Sie den kompakten aktiven Zustand:
systemctl is-active labex-heartbeat.service
Als Ausgabe wird active erwartet. Zeigen Sie den ausführlicheren Status an:
systemctl status labex-heartbeat.service --no-pager
Der Status enthält nun eine Main-PID. Stoppen Sie den Dienst und untersuchen Sie das Ergebnis:
sudo systemctl stop labex-heartbeat.service
systemctl is-active labex-heartbeat.service || true
Als Zustand wird inactive erwartet. Starten Sie den Dienst erneut und verwenden Sie anschließend restart, um den laufenden Prozess in einem Schritt zu ersetzen:
sudo systemctl start labex-heartbeat.service
sudo systemctl restart labex-heartbeat.service
systemctl show labex-heartbeat.service -p ActiveState -p SubState -p MainPID
Am Ende dieses Schritts sollte der Dienst ActiveState=active und SubState=running aufweisen.
Die Aktivierung beim Systemstart konfigurieren
In diesem Schritt unterscheiden Sie den aktuellen Laufzeitstatus eines Dienstes davon, ob er für zukünftige Systemstarts aktiviert ist.
Der Dienst ist aus dem vorherigen Schritt aktiv, aber die Einrichtung hat seine Unit-Datei deaktiviert. Prüfen Sie den Aktivierungsstatus:
systemctl is-enabled labex-heartbeat.service || true
Aktivieren Sie den Dienst:
sudo systemctl enable labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service
Durch die Aktivierung werden Verknüpfungen erstellt, die den Dienst mit einem Systemstartziel verbinden. Ein bereits laufender Dienst muss dadurch nicht neu gestartet werden.
Üben Sie das Entfernen dieser Verknüpfungen für den Systemstart:
sudo systemctl disable labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service || true
Der Dienst kann weiterhin aktiv sein, obwohl die Ausgabe jetzt disabled lautet. Aktivieren Sie ihn für den endgültigen Zustand des Labs wieder:
sudo systemctl enable labex-heartbeat.service
Bestätigen Sie beide unabhängigen Eigenschaften:
systemctl is-active labex-heartbeat.service
systemctl is-enabled labex-heartbeat.service
Dienstprotokolle mit journalctl abfragen
In diesem Schritt lesen Sie aktuelle Dienstausgaben aus dem systemd-Journal und speichern einen gezielten Schnappschuss.
Von systemd verwaltete Dienste senden ihre Standardausgabe und Standardfehlerausgabe normalerweise an das Journal. Fragen Sie nur die Unit des Übungsdienstes ab:
sudo journalctl -u labex-heartbeat.service -n 10 --no-pager
Die Option -u wählt eine Unit aus, -n 10 beschränkt die Ausgabe auf die zehn neuesten Einträge und --no-pager gibt sie direkt aus. Sie sollten aktuelle Heartbeat-Einträge sehen. Die Startmeldung kann während des weiteren Betriebs des Dienstes bereits außerhalb dieser begrenzten Ansicht liegen.
Beschränken Sie die Ergebnisse auf ein aktuelles Zeitfenster:
sudo journalctl -u labex-heartbeat.service --since "5 minutes ago" --no-pager
Filtern Sie nach der Priorität Warnung oder höher. Keine Ausgabe ist ein gesunder und gültiger Zustand, wenn der Dienst keine Warnung protokolliert hat:
sudo journalctl -u labex-heartbeat.service -p warning --since "5 minutes ago" --no-pager
Speichern Sie einen aktuellen, auf die Unit beschränkten Schnappschuss im Projektarbeitsbereich:
cd /home/labex/project/service-lab
sudo journalctl -u labex-heartbeat.service -n 20 --no-pager > service-journal.txt
tail -n 5 service-journal.txt
Ein herkömmliches Textprotokoll verfolgen
In diesem Schritt untersuchen Sie /var/log und verfolgen ein Textprotokoll, während neue Einträge eintreffen.
Die Hierarchie /var/log enthält viele herkömmliche System- und Anwendungsprotokolle. Listen Sie eine kleine Auswahl auf:
ls -lh /var/log | head -n 12
Lesen Sie die neuesten Einträge des Übungsdienstes:
tail -n 5 /var/log/labex-heartbeat.log
Die Option -f verfolgt eine Datei und zeigt neue Zeilen an, während ein anderer Prozess sie an die Datei anhängt:
tail -f /var/log/labex-heartbeat.log
Warten Sie, bis mindestens zwei neue Heartbeat-Zeilen angezeigt werden, und drücken Sie dann Ctrl+C. Dadurch wird tail unterbrochen, aber nicht der Dienst beendet, der das Protokoll schreibt.
Filtern Sie die Heartbeat-Zeilen und zeigen Sie die drei neuesten an:
grep '^heartbeat ' /var/log/labex-heartbeat.log | tail -n 3
Speichern Sie eine Auswahl von fünf Zeilen im Projektarbeitsbereich:
cd /home/labex/project/service-lab
tail -n 5 /var/log/labex-heartbeat.log > traditional-log-sample.txt
cat traditional-log-sample.txt
Einen fehlgeschlagenen Dienst diagnostizieren und wiederherstellen
In diesem Schritt erzeugen Sie einen kontrollierten Konfigurationsfehler, ermitteln ihn anhand des Dienststatus und der Protokolle und stellen den ordnungsgemäßen Betrieb wieder her.
Stoppen Sie den Übungsdienst und sichern Sie seine einfache Konfiguration:
sudo systemctl stop labex-heartbeat.service
sudo cp /etc/labex-heartbeat.conf /etc/labex-heartbeat.conf.bak
Ersetzen Sie das numerische Intervall durch einen ungültigen Wert. Dadurch wird absichtlich nur der Übungsdienst beeinträchtigt:
sudo sed -i 's/^INTERVAL=2$/INTERVAL=invalid/' /etc/labex-heartbeat.conf
Versuchen Sie, den Dienst zu starten. Eine Fehlermeldung wird erwartet:
sudo systemctl start labex-heartbeat.service || true
Untersuchen Sie den fehlgeschlagenen Zustand:
systemctl status labex-heartbeat.service --no-pager || true
systemctl is-failed labex-heartbeat.service
Der Status zeigt, dass der Prozess beendet wurde. Das Journal nennt den anwendungsspezifischen Grund:
sudo journalctl -u labex-heartbeat.service -n 10 --no-pager
Suchen Sie nach configuration error: INTERVAL must be a positive integer. Stellen Sie die funktionierende Konfiguration wieder her, löschen Sie den aufgezeichneten Fehlerzustand und starten Sie den Dienst erneut:
sudo mv /etc/labex-heartbeat.conf.bak /etc/labex-heartbeat.conf
sudo systemctl reset-failed labex-heartbeat.service
sudo systemctl start labex-heartbeat.service
Bestätigen Sie die Wiederherstellung:
systemctl is-active labex-heartbeat.service
cat /etc/labex-heartbeat.conf
Der Dienst sollte active sein, und die Konfiguration sollte wieder INTERVAL=2 enthalten.
Zusammenfassung
Sie haben Prozesse, Dienste, den aktiven Zustand und die Aktivierung beim Systemstart unterschieden. Sie haben eine systemd-Unit untersucht, einen sicheren Übungsdienst mit systemctl gesteuert und seine Einträge mit journalctl abgefragt.
Außerdem haben Sie /var/log untersucht, laufende Textausgaben mit tail -f verfolgt, Status und Protokolle gemeinsam zur Erklärung eines kontrollierten Fehlers verwendet und den Dienst wiederhergestellt. Dieser Arbeitsablauf — zuerst den Zustand prüfen, dann die Protokolle — bildet eine praktische Grundlage für die grundlegende Fehlerbehebung bei Diensten.
