Einführung
In diesem Lab sammeln Sie praktische Erfahrungen bei der Verwaltung von Systemdiensten unter RHEL mithilfe des Befehls systemctl. Sie lernen, alle geladenen und aktiven Dienste aufzulisten, den Status spezifischer Dienste zu überprüfen und deren Laufzeitverhalten durch Starten, Stoppen und Neustarten zu steuern. Darüber hinaus erfahren Sie, wie Sie Dienstkonfigurationen neu laden, Dienste für den automatischen Start beim Booten aktivieren oder deaktivieren und die fortgeschrittenen Konzepte des Maskierens und Entmaskierens von Diensten verstehen, um deren Aktivierung zu verhindern.
Dieser praktische Leitfaden vermittelt Ihnen wesentliche Fähigkeiten für die Systemadministration, mit denen Sie den Lebenszyklus kritischer Dienste für den Betrieb Ihres RHEL-Systems effektiv überwachen und verwalten können.
Alle geladenen und aktiven Dienste mit systemctl anzeigen
In diesem Schritt lernen Sie, wie Sie automatisch gestartete Systemprozesse mithilfe des Befehls systemctl identifizieren. systemctl ist das primäre Werkzeug zur Verwaltung von systemd-Diensten in Red Hat Enterprise Linux.
Zuerst erkunden wir, wie man alle aktuell geladenen und aktiven Dienst-Units auflistet. Der Befehl systemctl list-units --type=service wird für diesen Zweck verwendet. Dieser Befehl zeigt Dienst-Units an, die der systemd-Daemon erfolgreich geparst und in den Speicher geladen hat und die aktuell aktiv sind.
Öffnen Sie Ihr Terminal in der RHEL-Umgebung. Sie sind bereits als Benutzer labex angemeldet und Ihr aktuelles Verzeichnis ist ~/project.
Führen Sie den folgenden Befehl aus, um alle geladenen und aktiven Dienst-Units aufzulisten:
systemctl list-units --type=service
Sie sehen eine Ausgabe ähnlich der folgenden, die verschiedene Dienste und deren Status anzeigt:
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing Service
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
...output omitted...
Lassen Sie uns die Spalten der Ausgabe aufschlüsseln:
- UNIT: Dies ist der Name der Dienst-Unit, der normalerweise auf
.serviceendet. - LOAD: Gibt an, ob der
systemd-Daemon die Konfiguration der Unit erfolgreich geparst und in den Speicher geladen hat.loadedbedeutet, dass dies erfolgreich war. - ACTIVE: Dies ist der übergeordnete Aktivierungsstatus der Unit.
activebedeutet im Allgemeinen, dass die Unit erfolgreich gestartet wurde. - SUB: Dies ist der untergeordnete Aktivierungsstatus, der detailliertere Informationen liefert. Bei laufenden Diensten ist
runningüblich. - DESCRIPTION: Eine kurze Beschreibung der Funktion des Dienstes.
Drücken Sie q, um den Befehl zu beenden.
Als Nächstes können Sie die Option --all mit systemctl list-units --type=service verwenden, um alle Dienst-Units unabhängig von ihrem Aktivierungsstatus (aktiv, inaktiv, fehlgeschlagen usw.) aufzulisten. Dies ist nützlich, um Dienste zu sehen, die installiert, aber aktuell nicht ausgeführt werden.
Führen Sie den folgenden Befehl aus:
systemctl list-units --type=service --all
Die Ausgabe enthält nun auch Dienste, die inactive sind oder sich in anderen Zuständen befinden, was einen umfassenderen Überblick bietet:
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing ...
auth-rpcgss-module.service loaded inactive dead Kernel Module ...
chronyd.service loaded active running NTP client/server
cpupower.service loaded inactive dead Configure CPU power ...
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
● display-manager.service not-found inactive dead display-manager.service
...output omitted...
Um schließlich den Status aller installierten Unit-Dateien zu sehen, einschließlich derer, die nicht geladen oder aktiv sind, können Sie systemctl list-unit-files --type=service verwenden. Dieser Befehl zeigt an, ob ein Dienst enabled (startet beim Booten), disabled (startet nicht beim Booten), static (kann nicht direkt aktiviert werden, wird aber möglicherweise von einer anderen Unit gestartet) oder masked (an der Aktivierung gehindert) ist.
Führen Sie den folgenden Befehl aus:
systemctl list-unit-files --type=service
Sie sehen eine Ausgabe ähnlich der folgenden, die den STATE und den VENDOR PRESET für jede Dienst-Unit-Datei angibt:
UNIT FILE STATE VENDOR PRESET
arp-ethers.service disabled disabled
atd.service enabled enabled
auditd.service enabled enabled
auth-rpcgss-module.service static -
autovt@.service alias -
blk-availability.service disabled disabled
...output omitted...
Dieser Befehl ist besonders nützlich, um zu verstehen, welche Dienste so konfiguriert sind, dass sie beim Systemstart automatisch geladen werden.
Status eines spezifischen Dienstes mit systemctl status überprüfen
In diesem Schritt lernen Sie, wie Sie den detaillierten Status eines bestimmten Dienstes mit dem Befehl systemctl status überprüfen. Dieser Befehl liefert umfassende Informationen über einen Dienst, einschließlich der Frage, ob er läuft, seiner Prozess-ID, der Speicherauslastung und aktueller Protokolleinträge.
Wir verwenden crond.service (den Cron-Daemon) als Beispiel. Der Cron-Daemon ist ein gängiger Dienst, der geplante Aufgaben verwaltet.
Öffnen Sie Ihr Terminal in der RHEL-Umgebung. Stellen Sie sicher, dass Sie sich in Ihrem Verzeichnis ~/project befinden.
Führen Sie den folgenden Befehl aus, um den Status von crond.service zu überprüfen:
systemctl status crond.service
Sie sehen eine detaillierte Ausgabe ähnlich der folgenden:
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
Main PID: 1089 (crond)
Tasks: 1 (limit: 35578)
Memory: 1.2M
CPU: 12ms
CGroup: /system.slice/crond.service
└─1089 /usr/sbin/crond -n
Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.
Lassen Sie uns die wichtigsten Felder in der Ausgabe untersuchen:
Loaded: Diese Zeile gibt an, ob die Konfigurationsdatei der Dienst-Unit verarbeitet wurde. Sie zeigt auch den Pfad zur Unit-Datei (/usr/lib/systemd/system/crond.service) und ihren Aktivierungsstatus (enabledbedeutet, dass sie so konfiguriert ist, dass sie beim Booten startet).Active: Dies ist entscheidend. Es zeigt den aktuellen Zustand des Dienstes an.active (running)bedeutet, dass der Dienst aktuell aktiv ist und seine Prozesse laufen. Es wird auch angezeigt, wie lange er bereits aktiv ist. Andere Zustände könnteninactive(läuft nicht),active (exited)(hat eine einmalige Aufgabe abgeschlossen) oderfailed(ist auf einen Fehler gestoßen) sein.Main PID: Die Prozess-ID (PID) des Hauptprozesses, der mit dem Dienst verknüpft ist, zusammen mit dem Befehlsnamen.Tasks: Die Anzahl der Aufgaben (Threads), die der Dienst aktuell verwendet.Memory: Die Speichermenge, die der Dienst verbraucht.CPU: Die vom Dienst verbrauchte CPU-Zeit.CGroup: Informationen über die Control Group, zu der der Dienst gehört, die für die Ressourcenverwaltung verwendet wird.- Die Zeilen unter
CGroupzeigen aktuelle Protokolleinträge, die sich auf den Dienst beziehen, und geben Einblicke in seinen Start und seine laufenden Aktivitäten.
Zusätzlich zu systemctl status gibt es einfachere Befehle, um schnell spezifische Aspekte des Zustands eines Dienstes zu überprüfen:
Um zu prüfen, ob ein Dienst aktiv ist:
systemctl is-active crond.serviceErwartete Ausgabe:
activeUm zu prüfen, ob ein Dienst aktiviert ist (konfiguriert für den Start beim Booten):
systemctl is-enabled crond.serviceErwartete Ausgabe:
enabledUm zu prüfen, ob ein Dienst fehlgeschlagen ist:
systemctl is-failed crond.serviceErwartete Ausgabe (bei korrektem Betrieb):
activeWenn ein Dienst Probleme beim Starten oder Ausführen hatte, würde dieser Befehl
failedzurückgeben.
Diese Befehle sind nützlich für Skripte oder schnelle Überprüfungen, wenn Sie nicht die vollständige, detaillierte Ausgabe von systemctl status benötigen.
Einen Dienst mit systemctl starten, stoppen und neu starten
In diesem Schritt lernen Sie, wie Sie den Lebenszyklus von Systemdiensten mithilfe von systemctl-Befehlen verwalten. Sie üben das Starten, Stoppen und Neustarten eines Dienstes. Für diese Übung verwenden wir einen Dummy-Dienst, den wir selbst erstellen. Dieser Ansatz stellt sicher, dass wir einen Dienst sicher manipulieren können, ohne kritische Systemfunktionen zu beeinträchtigen.
Erstellen wir zunächst eine einfache Dienst-Unit-Datei. Diese Datei definiert einen Dienst, der einfach alle paar Sekunden einen Zeitstempel in eine Protokolldatei schreibt.
Erstellen Sie eine neue Dienst-Unit-Datei namens mytest.service direkt im systemd-Systemverzeichnis mit nano:
sudo nano /etc/systemd/system/mytest.service
Fügen Sie den folgenden Inhalt in den nano-Editor ein:
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]: Enthält allgemeine Informationen über die Unit.Descriptionbietet einen menschenlesbaren Namen, undAfter=network.targetlegt fest, dass dieser Dienst nach dem Netzwerk gestartet werden soll.[Service]: Definiert das Verhalten des Dienstes.Type=simple: Gibt einen einfachen Diensttyp an, bei dem derExecStart-Befehl der Hauptprozess ist.ExecStart: Der Befehl, der beim Starten des Dienstes ausgeführt wird. Hier ist es eine Bash-Schleife, die alle 5 Sekunden eine Nachricht mit Zeitstempel in/tmp/mytest.logschreibt.ExecStop: Der Befehl, der beim Stoppen des Dienstes ausgeführt wird. Er schreibt eine Stopp-Nachricht in das Protokoll.Restart=on-failure: Konfiguriert den Dienst so, dass er neu gestartet wird, wenn er mit einem Status ungleich Null beendet wird.
[Install]: Enthält Informationen darüber, wie der Dienst installiert werden soll.WantedBy=multi-user.targetbedeutet, dass dieser Dienst gestartet werden soll, wenn das System den Multi-User-Runlevel erreicht.
Speichern Sie die Datei durch Drücken von Ctrl+X, dann Y zur Bestätigung und Enter.
Laden Sie nun den systemd-Daemon neu, damit die neue Dienstdatei erkannt wird:
sudo systemctl daemon-reload
Einen Dienst starten
Um einen Dienst zu starten, verwenden Sie den Befehl systemctl start.
Führen Sie den folgenden Befehl aus, um mytest.service zu starten. Beachten Sie, dass wir sudo verwenden müssen, da systemctl-Operationen normalerweise Root-Rechte erfordern.
sudo systemctl start mytest.service
Bei Erfolg gibt es keine unmittelbare Ausgabe.
Überprüfen Sie nun, ob der Dienst läuft, indem Sie seinen Status abfragen:
systemctl status mytest.service
Sie sollten eine Ausgabe sehen, die anzeigt, dass der Dienst active (running) ist:
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
Sie können auch die Protokolldatei überprüfen, um zu sehen, ob der Dienst Nachrichten schreibt:
tail -f /tmp/mytest.log
Sie sollten sehen, wie alle 5 Sekunden neue Zeilen erscheinen, ähnlich wie hier:
Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.
Drücken Sie Ctrl+C, um tail zu beenden.
Einen Dienst stoppen
Um einen laufenden Dienst zu stoppen, verwenden Sie den Befehl systemctl stop.
Führen Sie den folgenden Befehl aus, um mytest.service zu stoppen:
sudo systemctl stop mytest.service
Auch hier gibt es keine unmittelbare Ausgabe.
Überprüfen Sie, ob der Dienst gestoppt wurde:
systemctl status mytest.service
Die Ausgabe sollte nun Active: inactive (dead) anzeigen:
○ mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: inactive (dead) since ...
...output omitted...
Überprüfen Sie die Protokolldatei /tmp/mytest.log erneut. Sie sollten die Nachricht "My Test Service stopped." sehen und keine neuen "running"-Nachrichten mehr.
tail /tmp/mytest.log
Die Ausgabe sieht ähnlich aus wie diese:
Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Einen Dienst neu starten
Um einen Dienst neu zu starten, verwenden Sie den Befehl systemctl restart. Dieser Befehl stoppt den Dienst zuerst und startet ihn dann wieder. Dies ist nützlich, wenn Sie Änderungen an der Konfiguration eines Dienstes vorgenommen haben und diese wirksam werden sollen.
Führen Sie den folgenden Befehl aus, um mytest.service neu zu starten:
sudo systemctl restart mytest.service
Überprüfen Sie, ob der Dienst wieder läuft:
systemctl status mytest.service
Sie sollten wieder Active: active (running) sehen, und die Main PID wird wahrscheinlich eine neue Nummer sein, was darauf hinweist, dass ein neuer Prozess gestartet wurde.
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
Überprüfen Sie die Protokolldatei /tmp/mytest.log, um zu bestätigen, dass der Dienst wieder "running"-Nachrichten schreibt.
tail -f /tmp/mytest.log
Sie sollten eine "stopped"-Nachricht gefolgt von neuen "running"-Nachrichten sehen:
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.
Drücken Sie Ctrl+C, um tail zu beenden.
Konfigurationsänderungen auf einen Dienst anwenden
In diesem Schritt lernen Sie das Neuladen von Dienstkonfigurationen kennen. Einige Dienste können Änderungen an ihren Konfigurationsdateien anwenden, ohne dass ein vollständiger Neustart erforderlich ist. Dies wird als "Neuladen" (Reloading) des Dienstes bezeichnet. Das Neuladen wird im Allgemeinen dem Neustarten vorgezogen, da es Dienstausfallzeiten vermeidet und bestehende Verbindungen oder Zustände bewahrt. Wenn ein Dienst neu geladen wird, bleibt seine Prozess-ID (PID) normalerweise gleich, im Gegensatz zu einem vollständigen Neustart, bei dem sich die PID ändert.
Wir verwenden weiterhin unseren mytest.service aus dem vorherigen Schritt. Wir werden sein Verhalten ändern und dann versuchen, ihn neu zu laden, um zu sehen, was passiert.
Stellen Sie zunächst sicher, dass mytest.service läuft. Falls nicht, starten Sie ihn:
sudo systemctl start mytest.service
Überprüfen Sie seinen Status und notieren Sie sich die Main PID:
systemctl status mytest.service
Lassen Sie uns nun die Datei mytest.service ändern, um die Nachricht, die er protokolliert, und das Intervall anzupassen. Wir ändern die Protokollnachricht und die sleep-Dauer.
Öffnen Sie /etc/systemd/system/mytest.service mit nano:
sudo nano /etc/systemd/system/mytest.service
Ändern Sie die ExecStart-Zeile wie folgt, indem Sie die Nachricht anpassen und die sleep-Zeit von 5 auf 2 Sekunden ändern:
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
Speichern Sie die Datei durch Drücken von Ctrl+X, dann Y und Enter.
Nach dem Speichern der Änderungen müssen Sie systemd mitteilen, dass sich die Konfiguration des Dienstes geändert hat.
sudo systemctl daemon-reload
Versuchen wir nun, den Dienst neu zu laden, um die Änderungen anzuwenden:
sudo systemctl reload mytest.service
Sie werden wahrscheinlich auf einen Fehler stoßen:
Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.
Dieser Fehler tritt auf, weil unser einfacher Dienst nicht so konfiguriert ist, dass er eine Neuladeanforderung verarbeiten kann. Damit ein Dienst neu geladen werden kann, muss seine Unit-Datei eine ExecReload-Direktive enthalten, die den Befehl zum Neuladen der Konfiguration angibt. Da dies bei unserem mytest.service fehlt, weiß systemd nicht, wie er ihn neu laden soll.
In solchen Situationen bietet systemd einen praktischen Befehl: reload-or-restart. Dieser Befehl versucht, den Dienst neu zu laden, aber wenn das Neuladen nicht unterstützt wird, greift er auf den Neustart des Dienstes zurück. Dies ist oft ein sichererer und effektiverer Weg, um Konfigurationsänderungen anzuwenden.
Verwenden wir jetzt reload-or-restart:
sudo systemctl reload-or-restart mytest.service
Dieser Befehl sollte erfolgreich sein. Überprüfen Sie nun erneut den Status des Dienstes:
systemctl status mytest.service
Beachten Sie die Main PID. Da unser Dienst neu gestartet wurde (weil er nicht neu geladen werden konnte), werden Sie feststellen, dass die Main PID eine neue Nummer ist. Dies bestätigt, dass der alte Prozess gestoppt und ein neuer mit der aktualisierten Konfiguration gestartet wurde.
Überprüfen wir abschließend die Datei /tmp/mytest.log, um zu sehen, ob die Änderungen wirksam geworden sind.
tail -f /tmp/mytest.log
Sie sollten sehen, wie die neue Protokollnachricht "My Test Service (reloaded) is running." alle 2 Sekunden erscheint. Drücken Sie Ctrl+C, um tail zu beenden.
Dienste beim Booten mit systemctl aktivieren und deaktivieren
In diesem Schritt lernen Sie, wie Sie Dienste so konfigurieren, dass sie automatisch beim Systemstart gestartet werden (aktivieren) oder deren Start beim Booten verhindern (deaktivieren). Dies ist entscheidend für die Verwaltung von Systemressourcen und um sicherzustellen, dass notwendige Dienste beim Systemstart verfügbar sind.
In einer typischen systemd-Umgebung erstellt das Aktivieren eines Dienstes symbolische Links in den entsprechenden systemd-Konfigurationsverzeichnissen (z. B. /etc/systemd/system/multi-user.target.wants/), die auf die Unit-Datei des Dienstes zeigen. Das Deaktivieren eines Dienstes entfernt diese Links.
Da wir uns in einer containerisierten Umgebung befinden, in der systemd im traditionellen Sinne möglicherweise nicht vollständig betriebsbereit ist, erstellen die Befehle enable und disable möglicherweise keine tatsächlichen Symlinks im Verzeichnis /etc/systemd/system, die über Container-Neustarts hinweg bestehen bleiben. systemctl verarbeitet diese Befehle jedoch trotzdem und aktualisiert seinen internen Status, was wir beobachten werden.
Wir verwenden weiterhin unseren mytest.service für diese Demonstration.
Stellen Sie zunächst sicher, dass mytest.service aus dem vorherigen Schritt gestoppt ist:
sudo systemctl stop mytest.service
Einen Dienst aktivieren
Um einen Dienst zu aktivieren, verwenden Sie den Befehl systemctl enable. Dieser Befehl konfiguriert den Dienst so, dass er automatisch beim Systemstart gestartet wird.
Führen Sie den folgenden Befehl aus, um mytest.service zu aktivieren:
sudo systemctl enable mytest.service
Sie sehen möglicherweise eine Ausgabe ähnlich der folgenden, die darauf hinweist, dass in einer vollständigen systemd-Umgebung ein symbolischer Link erstellt würde:
Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.
Überprüfen Sie nun mit systemctl is-enabled, ob der Dienst aktiviert ist:
systemctl is-enabled mytest.service
Erwartete Ausgabe:
enabled
Dies bestätigt, dass systemctl nun mytest.service als für den Bootvorgang aktiviert betrachtet.
Sie können das Aktivieren und Starten eines Dienstes auch mit der Option --now in einem Befehl kombinieren. Dies ist eine bequeme Möglichkeit, sicherzustellen, dass ein Dienst sowohl sofort läuft als auch für zukünftige Systemstarts konfiguriert ist.
Deaktivieren wir ihn zunächst, um die --now-Demonstration vorzubereiten:
sudo systemctl disable mytest.service
Aktivieren und starten Sie ihn nun gleichzeitig:
sudo systemctl enable --now mytest.service
Überprüfen Sie seinen Status und Aktivierungszustand:
systemctl status mytest.service
systemctl is-enabled mytest.service
Sie sollten Active: active (running) vom status-Befehl und enabled vom is-enabled-Befehl sehen.
Einen Dienst deaktivieren
Um einen Dienst zu deaktivieren, verwenden Sie den Befehl systemctl disable. Dieser Befehl entfernt die Konfiguration, die dazu führt, dass der Dienst beim Booten startet.
Führen Sie den folgenden Befehl aus, um mytest.service zu deaktivieren:
sudo systemctl disable mytest.service
Sie sehen möglicherweise eine Ausgabe, die das Entfernen des symbolischen Links anzeigt:
Removed /etc/systemd/system/multi-user.target.wants/mytest.service.
Überprüfen Sie nun, ob der Dienst deaktiviert ist:
systemctl is-enabled mytest.service
Erwartete Ausgabe:
disabled
Ähnlich wie beim Aktivieren können Sie das Deaktivieren und Stoppen eines Dienstes mit der Option --now kombinieren. Dies stoppt den Dienst sofort und verhindert, dass er bei zukünftigen Systemstarts geladen wird.
sudo systemctl disable --now mytest.service
Überprüfen Sie seinen Status und Aktivierungszustand:
systemctl status mytest.service
systemctl is-enabled mytest.service
Sie sollten Active: inactive (dead) vom status-Befehl und disabled vom is-enabled-Befehl sehen.
Dies schließt die Demonstration zum Aktivieren und Deaktivieren von Diensten ab. Denken Sie daran, dass diese Befehle in einer echten systemd-Umgebung direkt die Boot-Konfiguration manipulieren.
Dienste mit systemctl maskieren und entmaskieren
In diesem letzten Schritt lernen Sie das Maskieren und Entmaskieren von Diensten kennen. Das Maskieren eines Dienstes ist eine leistungsstarke Methode, um zu verhindern, dass er manuell oder automatisch beim Booten gestartet wird.
Wenn Sie einen Dienst maskieren, erstellt systemd einen symbolischen Link von /etc/systemd/system/<service-name>.service nach /dev/null, wodurch die Dienst-Unit-Datei für systemd effektiv unzugänglich gemacht wird. Dies ist eine stärkere Alternative zu disable.
Dieser Mechanismus funktioniert am besten für Dienste, die in /usr/lib/systemd/system definiert sind, wo Pakete ihre Dienstdateien installieren. Der Befehl mask erstellt eine überschreibende "leere" Datei in /etc/systemd/system. Wie Sie jedoch festgestellt haben, kann der Befehl fehlschlagen, wenn Sie versuchen, einen Dienst zu maskieren, den Sie direkt in /etc/systemd/system erstellt haben (wie unseren mytest.service), da er so konzipiert ist, dass er keine bestehende Konfigurationsdatei überschreibt, was zu Datenverlust führen würde.
Um das Maskieren korrekt zu demonstrieren, verwenden wir einen bereits vorhandenen Dienst: atd.service.
Überprüfen wir zunächst den aktuellen Status von atd.service. Er sollte aktiv und aktiviert sein.
systemctl status atd.service
Die Ausgabe sieht ähnlich aus wie diese und zeigt, dass der Dienst aktiv ist und läuft:
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
Docs: man:atd(8)
Main PID: 1222 (atd)
Tasks: 1 (limit: 22509)
Memory: 900.0K
CPU: 5ms
CGroup: /system.slice/atd.service
└─1222 /usr/sbin/atd -f
Einen Dienst maskieren
Es ist bewährte Praxis, einen Dienst zu stoppen, bevor man ihn maskiert.
sudo systemctl stop atd.service
Führen Sie nun den folgenden Befehl aus, um atd.service zu maskieren:
sudo systemctl mask atd.service
Sie sehen eine Ausgabe, die die Erstellung eines symbolischen Links nach /dev/null anzeigt:
Created symlink /etc/systemd/system/atd.service → /dev/null.
Versuchen Sie nun, den maskierten Dienst zu starten:
sudo systemctl start atd.service
Sie erhalten eine Fehlermeldung, die darauf hinweist, dass der Dienst maskiert ist:
Failed to start atd.service: Unit atd.service is masked.
Sie können den Status des Dienstes auch mit systemctl list-unit-files überprüfen:
systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt
Die Ausgabe sollte für atd.service masked anzeigen:
atd.service masked enabled
Dies bestätigt, dass der Dienst nun maskiert ist und nicht gestartet werden kann.
Einen Dienst entmaskieren
Um einen Dienst zu entmaskieren, verwenden Sie den Befehl systemctl unmask. Dieser Befehl entfernt den symbolischen Link nach /dev/null und stellt die ursprüngliche Dienstdatei aus /usr/lib/systemd/system wieder her.
Führen Sie den folgenden Befehl aus, um atd.service zu entmaskieren:
sudo systemctl unmask atd.service
Sie sehen eine Ausgabe, die das Entfernen des symbolischen Links anzeigt:
Removed "/etc/systemd/system/atd.service".
Starten Sie den Dienst nach dem Entmaskieren erneut, da unmask nur den /dev/null-Link entfernt und den Dienst nicht automatisch für Sie neu startet.
sudo systemctl start atd.service
Überprüfen Sie nun den Status des Dienstes:
systemctl status atd.service
Sie sollten Active: active (running) sehen, ähnlich wie hier:
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
Docs: man:atd(8)
Main PID: 7372 (atd)
Tasks: 1 (limit: 22509)
Memory: 868.0K
CPU: 6ms
CGroup: /system.slice/atd.service
└─7372 /usr/sbin/atd -f
Dies schließt das Lab zur Steuerung von Diensten und Daemons ab. Sie haben gelernt, wie man Dienste mit systemctl auflistet, startet, stoppt, neu startet, neu lädt, aktiviert, deaktiviert, maskiert und entmaskiert.
Zusammenfassung
In diesem Lab haben wir praktische Erfahrungen bei der Verwaltung von Systemdiensten mithilfe des Befehls systemctl gesammelt, selbst in einer containerisierten Umgebung, in der systemd möglicherweise nicht das primäre Init-System ist. Wir haben gelernt, wie man alle geladenen und aktiven Dienst-Units mit systemctl list-units --type=service auflistet und die Spalten UNIT, LOAD, ACTIVE und SUB zur Interpretation der Dienstzustände verwendet.
Darüber hinaus haben wir wesentliche Dienstverwaltungsoperationen erkundet: das Überprüfen des Status eines spezifischen Dienstes mit systemctl status sowie die Steuerung des Dienstlebenszyklus durch Starten, Stoppen und Neustarten. Wir haben auch behandelt, wie man Dienstkonfigurationen neu lädt, Dienste aktiviert und deaktiviert, um ihr Verhalten beim Booten zu steuern, sowie die fortgeschrittenen Konzepte des Maskierens und Entmaskierens von Diensten, um deren Start zu verhindern. Dieser umfassende Satz an Fähigkeiten bietet eine solide Grundlage für die Verwaltung von Diensten auf RHEL-Systemen.



