systemctl
systemctl - Steuerung des Systemd-Systems und des Diensteverwalters
Beschreibung
Installation
Syntax
systemctl [OPTIONEN…] BEFEHL [UNIT…]
Optionen
Parameter
Umgebungsvariablen
Exit-Status
Anwendung
Fehlerbehebung
Konfiguration
Dateien
Anhang
Siehe auch
Dokumentation
Man-Pages
Info-Pages
Links
Projekt
Weblinks
TMP
Beschreibung
- systemctl kann zum Prüfen und Steuern des Zustandes des »Systemd«-Systems und -Diensteverwalters verwandt werden.
- Bitte lesen Sie systemd(1) für eine Einführung in die grundlegenden Konzepte und Funktionalitäten, die dieses Werkezeug verwaltet.
- Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken.
- Alle Dienste präsentiert etwa "systemctl --type=service".
- Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige.
- Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte.
- Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running").
- In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit.
- Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot.
- Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an
- In bestimmten Situationen erzeugt Systemd selbst eine Unit.
- Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes.
- Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte.
- Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.
Anwendung
Dienste verwalten
Der grundlegende Zweck eines Init-Systems ist die Initialisierung der Komponenten, die nach dem Booten des Linux-Kernels gestartet werden müssen (traditionell als „userland“-Komponenten bekannt).
- Das Init-System wird auch dazu verwendet, Dienste und Daemons für den Server zu jedem Zeitpunkt während des Systembetriebs zu verwalten.
- Vor diesem Hintergrund beginnen wir mit einigen grundlegenden Operationen zur Verwaltung von Diensten.
In systemd sind die meisten Aktionen auf „Einheiten“ (sog.
- Units) ausgerichtet, wobei es sich um Ressourcen handelt, die systemd verwalten kann.
- Einheiten werden nach der Art der Ressource, die sie repräsentieren, kategorisiert und mit Dateien definiert, die als Unit-Dateien bekannt sind.
- Die Art jeder Einheit kann aus dem Suffix am Ende der Datei abgeleitet werden.
Für Dienstverwaltungsaufgaben ist die Zieleinheit die Diensteinheiten, die Unit-Dateien mit dem Suffix .service aufweisen.
- Bei den meisten Dienstverwaltungsbefehlen können Sie jedoch das Suffix .service weglassen, da systemd intelligent genug ist, um zu wissen, dass Sie bei der Verwendung von Dienstverwaltungsbefehlen wahrscheinlich an einem Dienst arbeiten möchten.
Starten und beenden
Um einen systemd-Dienst zu starten, indem Anweisungen in der Unit-Datei des Dienstes ausgeführt werden, verwenden Sie den Befehl start.
- Wenn Sie als Nicht-root-Benutzer arbeiten, müssen Sie sudo verwenden, da dies den Status des Betriebssystems beeinflusst:
# systemctl start application.service
Wie bereits erwähnt, weiß systemd, nach *.service-Dateien für die Dienstverwaltungsbefehle zu suchen, sodass der Befehl auch einfach wie folgt eingegeben werden könnte:
# systemctl start application
Obwohl Sie das obige Format für die allgemeine Verwaltung verwenden können, verwenden wir aus Gründen der Übersichtlichkeit für die restlichen Befehle das Suffix .service, um das Ziel, an dem wir arbeiten, explizit zu kennzeichnen.
Um einen derzeit laufenden Dienst zu stoppen, können Sie stattdessen den Befehl stop verwenden:
# systemctl stop application.service
Neustarten und Neuladen
Um einen laufenden Dienst neu zu starten, können Sie den Befehl restart verwenden:
# systemctl restart application.service
Wenn die betreffende Anwendung ihre Konfigurationsdateien neu laden kann (ohne Neustart), können Sie den Befehl reload erteilen, um diesen Prozess zu starten:
# systemctl reload application.service
Wenn Sie nicht sicher sind, ob der Dienst die Funktionalität zum Neuladen seiner Konfiguration hat, können Sie den Befehl reload-or-restart erteilen.
- Dadurch wird die vorhandene Konfiguration, sofern verfügbar, neu geladen.
- Andernfalls startet der Befehl den Dienst, sodass die neue Konfiguration abgerufen wird:
# systemctl reload-or-restart application.service
Aktivieren und Deaktivieren von Diensten
Die obigen Befehle sind für das Starten oder Anhalten von Diensten während der aktuellen Sitzung nützlich.
- Um systemd anzuweisen, Dienste beim Booten automatisch zu starten, müssen Sie sie aktivieren.
Um einen Dienst beim Booten zu starten, verwenden Sie den Befehl enable:
# systemctl enable application.service
Dadurch wird ein symbolischer Link von der Kopie der Dienst-Datei des Systems (normalerweise in /lib/systemd/system oder /etc/systemd/system) zu dem Speicherort auf Festplatte, wo systemd nach Autostart-Dateien sucht (normalerweise /etc/systemd/system/some_target.target.wants.
- Wir werden später in diesem Leitfaden darauf eingehen, was ein Ziel (target) ist).
Um das automatische Starten des Dienstes zu deaktivieren, können Sie Folgendes eingeben:
# systemctl disable application.service
Dadurch wird der symbolische Link entfernt, der angab, dass der Dienst automatisch gestartet werden sollte.
Denken Sie daran, dass das Aktivieren eines Dienstes diesen nicht in der aktuellen Sitzung startet.
- Wenn Sie den Dienst starten und ihn auch beim Booten aktivieren möchten, müssen Sie sowohl den Befehl start als auch den Befehl enable erteilen.
Status
Um den Status eines Dienstes auf Ihrem System zu überprüfen, können Sie den Befehl status verwenden:
# systemctl status application.service
Dadurch erhalten Sie den Dienststatus, die cgroup-Hierarchie und die ersten paar Protokollzeilen.
Wenn Sie beispielsweise den Status eines Nginx-Servers überprüfen, sehen Sie möglicherweise eine Ausgabe wie diese:
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
Dadurch erhalten Sie einen schönen Überblick über den aktuellen Status der Anwendung und Sie werden über alle Probleme und eventuell erforderliche Maßnahmen informiert.
Es gibt auch Methoden zur Überprüfung bestimmter Zustände.
- Um beispielsweise zu überprüfen, ob eine Einheit derzeit aktiv ist (läuft), können Sie den Befehl is-active verwenden:
# systemctl is-active application.service
Dies gibt den aktuellen Zustand der Einheit zurück, der normalerweise active oder inactive ist.
- Der Exit-Code ist „0“, wenn er aktiv ist, wodurch das Ergebnis in Shell-Skripten einfacher zu parsen ist.
Um zu sehen, ob die Einheit aktiviert ist, können Sie den Befehl is-enabled verwenden:
# systemctl is-enabled application.service
Dies gibt aus, ob der Dienst enabled oder disabled ist und setzt den Exit-Code erneut auf „0“ oder „1“, abhängig von der Antwort auf die Befehlsfrage.
Eine dritte Überprüfung ist, ob sich die Einheit in einem fehlerhaften Zustand befindet.
- Dies deutet darauf hin, dass es ein Problem beim Starten der betreffenden Einheit gab:
# systemctl is-failed application.service
Dies gibt bei ordnungsgemäßer Ausführung active zurück oder failed, wenn ein Fehler aufgetreten ist.
- Wurde die Einheit absichtlich angehalten, kann unknown oder inactive zurückgegeben werden.
- Ein Exit-Status von „0“ gibt an, dass ein Fehler aufgetreten ist, und ein Exit-Status von „1“ zeigt jeden anderen Status an.
Systemstatus
Die bisherigen Befehle haben sich für die Verwaltung einzelner Dienste als nützlich erwiesen, doch sind sie nicht sehr hilfreich, um den aktuellen Zustand des Systems zu untersuchen.
- Es gibt eine Reihe von systemctl-Befehlen, die diese Informationen bereitstellen.
Auflisten aktueller Einheiten
Um eine Liste aller aktiven Einheiten zu sehen, von denen systemd Kenntnis hat, können wir den Befehl list-units verwenden:
# systemctl list-units
Dies zeigt eine Liste aller Einheiten, die systemd derzeit im System aktiv hat.
- Die Ausgabe sieht in etwa folgendermaßen aus:
UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDomain Name System/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . .
Die Ausgabe weist die folgenden Spalten auf:
- UNIT: der systemd-Einheitenname
- LOAD: ob die Konfiguration der Einheit durch systemd geparst wurde.
- Die Konfiguration von geladenen Einheiten wird im Speicher gespeichert.
- ACTIVE: ein zusammenfassender Status darüber, ob die Einheit aktiv ist.
- Dies ist normalerweise eine recht einfache Möglichkeit, um festzustellen, ob ie die Einheit erfolgreich gestartet wurde oder nicht.
- SUB: Dies ist ein untergeordneter Status, der detailliertere Informationen über die Einheit anzeigt.
- Dies variiert oft nach Art der Einheit, Status und der tatsächlichen Methode, in der die Einheit ausgeführt wird.
- DESCRIPTION: Eine kurze Textbeschreibung dessen, was die Einheit ist bzw. tut.
Da der Befehl list-units standardmäßig nur aktive Einheiten anzeigt, zeigen alle obigen Einträge in der Spalte LOAD loaded und active in der Spalte ACTIVE.
- Diese Anzeige ist tatsächlich das Standardverhalten von systemctl bei dem Aufruf ohne zusätzliche Befehle.
Daher sehen Sie dasselbe, wenn Sie systemctl ohne Argumente aufrufen:
# systemctl
Durch Hinzufügen von zusätzlichen Flags können wir systemctl anweisen, andere Informationen auszugeben.
- Um beispielsweise alle Einheiten zu sehen, die systemd geladen hat (oder versucht hat zu laden), unabhängig davon, ob sie derzeit aktiv sind, können Sie das Flag --all wie folgt verwenden:
# systemctl list-units --all
Dies zeigt jede Einheit an, die systemd geladen oder versucht hat zu laden, unabhängig von ihrem aktuellen Zustand im System.
- Einige Einheiten werden nach der Ausführung inaktiv und einige Einheiten, die systemd versucht hat zu laden, wurden möglicherweise nicht auf der Festplatte gefunden.
Sie können andere Flags verwenden, um diese Ergebnisse zu filtern.
- Beispielsweise können wir das Flag --state= verwenden, um die Zustände LOAD, ACTIVE oder SUB anzugeben, die wir sehen möchten.
- Sie müssen das Flag --all beibehalten, damit systemctl die Anzeige nicht aktiver Einheiten erlaubt:
# systemctl list-units --all --state=inactive
Ein weiterer gebräuchlicher Filter ist der Filter --type=.
- Wir können systemctl anweisen, nur Einheiten der Art anzuzeigen, an der wir interessiert sind.
- Um beispielsweise nur aktive Diensteinheiten zu sehen, können wir verwenden:
# systemctl list-units --type=service
Unit-Dateien auflisten
Der Befehl list-units zeigt nur Einheiten an, die systemd versucht hat zu parsen und in den Speicher zu laden.
- Da systemd nur Einheiten liest, von denen es glaubt, dass sie benötigt werden, beinhaltet dies nicht unbedingt alle verfügbaren Einheiten im System.
- Um alle verfügbaren Unit-Datei innerhalb der systemd-Pfade anzuzeigen, einschließlich derjenigen, die systemd nicht versucht hat zu laden, können Sie stattdessen den Befehl list-unit-files verwenden:
# systemctl list-unit-files
Units (Einheiten) sind Repräsentationen von Ressourcen, von denen systemd Kenntnis hat.
- Da systemd nicht unbedingt alle Unit-Definitionen in dieser Ansicht gelesen hat, zeigt es nur Informationen über die Dateien selbst an.
- Die Ausgabe hat zwei Spalten: die Unit-Datei und den Zustand.
UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static dev-hugepages.mount static dev-mqueue.mount static proc-fs-nfsd.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . .
Der Zustand ist in der Regel enabled (aktiviert), disabled (deaktiviert), static (statisch) oder masked (maskiert).
- In diesem Zusammenhang bedeutet statisch, dass die Unit-Datei keinen Abschnitt install enthält, der zur Aktivierung einer Einheit verwendet wird.
- Daher können diese Einheiten nicht aktiviert werden.
- Normalerweise bedeutet dies, dass die Einheit eine einmalige Aktion ausführt oder nur als Abhängigkeit einer anderen Einheit verwendet wird und nicht allein ausgeführt werden sollte.
Die Bedeutung von masked werden wir in Kürze besprechen.
Einheiten verwalten
Bisher haben wir mit Diensten gearbeitet und Informationen über die Einheit und die Unit-Dateien angezeigt, von denen systemd Kenntnis hat.
- Mit einigen zusätzlichen Befehlen können wir jedoch spezifischere Informationen über Einheiten herausfinden.
Unit-Datei anzeigen
Um die Unit-Datei anzuzeigen, die systemd in sein System geladen hat, können Sie den Befehl cat verwenden (dieser wurde in systemd Version 209 hinzugefügt).
- Um beispielsweise die Unit-Datei des atd Scheduling-Daemons zu sehen, könnten wir Folgendes eingeben:
# systemctl cat atd.service
[Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target
Die Ausgabe ist die Unit-Datei, die dem aktuell laufenden systemd-Prozess bekannt ist.
- Dies kann wichtig sein, wenn Sie kürzlich Unit-Dateien geändert haben oder wenn Sie bestimmte Optionen in einem Unit-Dateifragment überschreiben (wir werden dies später behandeln).
Abhängigkeiten anzeigen
Um den Abhängigkeitsbaum einer Einheit anzuzeigen, können Sie den Befehl list-dependencies verwenden:
# systemctl list-dependencies sshd.service
Dadurch wird eine Hierarchie angezeigt, die die Abhängigkeiten abbildet, die behandelt werden müssen, um die betreffende Einheit zu starten.
- Abhängigkeiten umfassen in diesem Zusammenhang diejenigen Einheiten, die entweder von darüber liegenden Einheiten benötigt oder gewünscht werden.
sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . .
Die rekursiven Abhängigkeiten werden nur für .target-Einheiten angezeigt, wobei diese Systemzustände angeben.
- Um alle Abhängigkeiten rekursiv aufzulisten, fügen Sie das Flag --all hinzu.
Um umgekehrte Abhängigkeiten (Einheiten, die von der angegebenen Einheit abhängen) anzuzeigen, können Sie dem Befehl das Flag --reverse hinzufügen.
- Andere nützliche Flags sind die Flags --before und --after, die zur Anzeige von Einheiten verwendet werden können, die von der angegebenen Einheit abhängen und vor bzw.
- nach sich selbst beginnen.
Überprüfen der Einheit-Eigenschaften
Um die untergeordneten Eigenschaften einer Einheit zu sehen, können Sie den Befehl show verwenden.
- Dadurch wird eine Liste der Eigenschaften angezeigt, die für die angegebene Einheit mit dem Format key=value festgelegt werden:
# systemctl show sshd.service
Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon . .
Wenn Sie eine einzelne Eigenschaft anzeigen möchten, können Sie das Flag -p mit dem Eigenschaftsnamen übergeben.
- Um beispielsweise die Konflikte zu sehen, die die Einheit sshd.service hat, können Sie Folgendes eingeben:
# systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target
Maskieren und Demaskieren von Einheiten
Wir haben im Abschnitt Verwaltung von Diensten gesehen, wie ein Dienst angehalten oder deaktiviert werden kann, aber systemd weist auch die Möglichkeit auf, eine Einheit durch Verknüpfung mit /dev/null automatisch oder manuell als vollständig nicht startbar zu markieren.
- Dies wird als Maskieren der Einheit bezeichnet und ist mit dem Befehl mask möglich:
# systemctl mask nginx.service
Dadurch wird verhindert, dass der Nginx-Dienst automatisch oder manuell gestartet wird, solange er maskiert ist.
Wenn Sie die list-unit-files überprüfen, sehen Sie, dass der Dienst nun als maskiert aufgelistet ist:
# systemctl list-unit-files
kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static ...
Wenn Sie versuchen, den Dienst zu starten, sehen Sie eine Nachricht wie diese:
# systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.
Um eine Einheit zu demaskieren und wieder für die Verwendung verfügbar zu machen, verwenden Sie den Befehl unmask:
# systemctl unmask nginx.service
Dadurch wird die Einheit in ihren vorherigen Zustand zurückversetzt, sodass sie gestartet oder aktiviert werden kann.
Bearbeiten von Unit-Dateien
Während das spezifische Format für Unit-Dateien außerhalb des Rahmens dieses Tutorials liegt, bietet systemctl integrierte Mechanismen für die Bearbeitung und Änderung von Unit-Dateien, falls Sie Anpassungen vornehmen müssen.
- Diese Funktionalität wurde in systemd Version 218 hinzugefügt.
Der Befehl edit öffnet standardmäßig eine Unit-Datei für die betreffende Einheit.
# systemctl edit nginx.service
Dabei handelt es sich um eine leere Datei, die zum Überschreiben oder Hinzufügen von Anweisungen zu Unit-Definition verwendet werden kann.
- Innerhalb des Verzeichnisses /etc/systemd/system wird ein Verzeichnis erstellt, das den Namen der Einheit mit angehängtem .d enthält.
- Für den nginx.service wird beispielsweise ein Verzeichnis namens nginx.service.d erstellt.
Innerhalb dieses Verzeichnisses wird ein Snippet namens override.conf erstellt.
- Wenn die Einheit geladen ist, führt systemd das Überschreiben-Snippet im Speicher mit der vollständigen Unit-Datei zusammen.
- Die Anweisungen des Snippets haben Vorrang vor denen, die in der ursprünglichen Unit-Datei zu finden sind.
Wenn Sie die vollständige Unit-Datei bearbeiten möchten, anstatt einen Snippet zu erstellen, können Sie das Flag --full übergeben:
# systemctl edit --full nginx.service
Dadurch wird die aktuelle Unit-Datei in den Editor geladen, wo sie geändert werden kann.
- Wird der Editor verlassen, wird die geänderte Datei in /etc/systemd/system geschrieben, wobei diese Datei Vorrang vor der Unit-Definition des Systems hat (normalerweise irgendwo in /lib/systemd/system zu finden).
Um alle von Ihnen vorgenommenen Ergänzungen zu entfernen, löschen Sie entweder das Konfigurationsverzeichnis .d der Einheit oder die geänderte Dienst-Datei aus /etc/systemd/system.
- Um beispielsweise ein Snippet zu entfernen, können wir Folgendes eingeben:
# rm -r /etc/systemd/system/nginx.service.d
Um eine vollständige geänderte Unit-Datei zu entfernen, geben wir Folgendes ein:
# rm /etc/systemd/system/nginx.service
Nach dem Löschen der Datei oder des Verzeichnisses sollten Sie den Prozess systemd neu laden, sodass er nicht mehr versucht, auf diese Dateien zu verweisen und wieder die Systemkopie verwendet.
- Geben Sie dazu Folgendes ein:
# systemctl daemon-reload
Anpassen des Systemzustands (Runlevel) mit Zielen
Ziele sind spezielle Unit-Dateien, die einen Systemzustand oder Synchronisationspunkt beschreiben.
- Wie andere Einheiten können die Dateien, die Ziele definieren, durch ihr Suffix identifiziert werden, was in diesem Fall .target ist.
- Ziele machen selbst nicht viel, sondern werden stattdessen verwendet, um andere Einheiten zusammenzufassen.
Dies kann verwendet werden, um das System in bestimmte Zustände zu bringen, ähnlich wie andere Init-Systeme Runlevel verwenden.
- Sie werden als Referenz verwendet, wenn bestimmte Funktionen verfügbar sind, sodass Sie anstelle der einzelnen Einheiten, die zur Erzeugung dieses Zustands benötigt werden, den gewünschten Zustand angeben können.
Beispielsweise gibt es ein swap.target, das verwendet, um anzugeben, dass Swap einsatzbereit ist.
- Einheiten, die Teil dieses Prozesses sind, können mit diesem Ziel synchronisieren, indem sie in ihrer Konfiguration angeben, dass sie WantedBy= oder RequiredBy= vom swap.target sind.
- Einheiten, für die Swap verfügbar sein muss, können diese Bedingung mit den Spezifikationen Wants=, Requires= und After= angeben, um die Art ihrer Beziehung anzugeben.
Abrufen und Einrichten des Standardziels
Der Prozess systemd hat ein Standardziel, das er beim Booten des Systems verwendet.
- Die Befriedigung der Kaskade von Abhängigkeiten von diesem einzelnen Ziel bringt das System in den gewünschten Zustand.
- Um das Standardziel für Ihr System zu finden, geben Sie Folgendes ein:
# systemctl get-default multi-user.target
Wenn Sie ein anderes Standardziel festlegen möchten, können Sie set-default verwenden.
- Wenn Sie beispielsweise eine grafische Arbeitsoberfläche installiert haben und möchten, dass das System standardmäßig in diese bootet, können Sie Ihr Standardziel entsprechend ändern:
# systemctl set-default graphical.target
Auflisten verfügbarer Ziele
Sie können eine Liste der auf Ihrem System verfügbaren Ziele erhalten, indem Sie Folgendes eingeben:
# systemctl list-unit-files --type=target
Im Gegensatz zu Runleveln können mehrere Ziele gleichzeitig aktiv sein.
- Ein aktives Ziel gibt an, dass systemd versucht hat, alle an das Ziel gebundene Einheiten zu starten und nicht versucht hat, sie wieder zu entfernen.
- Um alle aktiven Ziele zu sehen, geben Sie Folgendes ein:
# systemctl list-units --type=target
Isolieren von Zielen
Es ist möglich, alle mit einem Ziel verknüpften Einheiten zu starten und alle Einheiten zu stoppen, die nicht Teil des Abhängigkeitsbaums sind.
- Der Befehl, den wir dazu benötigen, heißt entsprechend isolate.
- Dies ist ähnlich wie das Ändern der Runlevel in anderen Init-Systemen.
Wenn Sie beispielsweise in einer grafischen Umgebung mit aktivem graphical.target arbeiten, können Sie das grafische System herunterfahren und das System in einen Multibenutzer-Befehlszeilenzustand versetzen, indem Sie multi-user.target isolieren.
- Da graphical.target von multi-user.target abhängt, aber nicht umgekehrt, werden alle grafischen Einheiten angehalten.
Sie sollten sich vor der Durchführung dieses Vorgangs die Abhängigkeiten des zu isolierenden Ziels ansehen, um sicherzustellen, dass Sie keine wichtigen Dienste anhalten.
# systemctl list-dependencies multi-user.target
Wenn Sie mit den Einheiten, die weiterhin aktiv bleiben sollen, zufrieden sind, können Sie das Ziel isolieren, indem Sie Folgendes eingeben:
# systemctl isolate multi-user.target
Verwenden von Shortcuts für wichtige Ereignisse
Es gibt Ziele, die für wichtige Ereignisse wie Ausschalten oder Neustart definiert sind.
- Allerdings verfügt systemctl auch über einige Shortcuts, die einige zusätzliche Funktionalität hinzufügen.
Um beispielsweise das System in den (Einzelbenutzer) Rettungsmodus zu versetzen, können Sie einfach den Befehl rescue verwenden, anstatt isolate rescue.target.
# systemctl rescue
Dies bietet die zusätzliche Funktionalität, alle angemeldeten Benutzer über das Ereignis zu alarmieren.
Um das System anzuhalten, können Sie den Befehl halt verwenden:
# systemctl halt
Um eine vollständiges Herunterfahren einzuleiten, können Sie den Befehl poweroff verwenden:
# systemctl poweroff
Ein Neustart kann mit dem Befehl reboot gestartet werden:
# systemctl reboot
Diese alarmieren angemeldete Benutzer, dass das Ereignis auftritt, was nur durch Ausführen oder Isolieren des Ziels nicht möglich ist.
- Zu beachten ist, dass die meisten Rechner die kürzeren, konventionelleren Befehle für diese Operationen verknüpfen, damit sie ordnungsgemäß mit systemd arbeiten.
Um beispielsweise das System neu zu starten, können Sie normalerweise eingeben:
# reboot
- Anwendungen
- Änderungen als root
- Alle vorgestellten Informationen darf jeder Nutzer abfragen.
- Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten.
- Dann lassen sich einzelne Units über »systemctl start« aktivieren beziehungsweise mit »systemctl stop« anhalten.
Der folgende Befehl fährt den SSH-Daemon hoch:
# systemctl start sshd.service
- Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen.
- Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus.
- Den SSH-Daemon könnten Sie folglich einfach mit »systemctl start sshd« anwerfen. "systemctl" wechselt natürlich auch Targets.
Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt:
# systemctl isolate rescue.target
- Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd.
Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn:
# systemctl disable sshd.service
In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an:
# systemctl enable sshd.service
Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind.
- Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen.
[[Image:Bild1.png|top]]
- Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde).
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Siehe auch
- systemd(1)
- journalctl(1)
- loginctl(1)
- machinectl(1)
- systemd.unit(5)
- systemd.resource-control(5)
- systemd.special(7)
- wall(1)
- systemd.preset(5)
- systemd.generator(7)
- glob(7)
- LSB 3.0.0 - http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
- systemd 250, SYSTEMCTL(1)
Links
Projekt-Homepage
Weblinks
Unit-Dateibefehle
- list-unit-files [MUSTER…]
Listet auf dem System installierte Units zusammen mit ihrem Freigabezustand (wie von
is-enabled) gemeldet) auf. Falls ein oder mehrere Muster angegeben sind, werden nur
Units, deren Name auf sie passen, gezeigt (Muster, die auf Unit-Dateisystempfade
passen, werden nicht unterstützt).
Anders als list-units wird dieser Befehl zusätzlich zu den explizit instanziierten
Units Vorlagenunits auflisten.
- enable UNIT…, enable PFAD…
Gibt eine oder mehrere Units oder Unit-Instanzen frei. Dies wird eine Gruppe von
Symlinks erzeugen, wie dies in dem Abschnitt »[Install]« der angezeigten
Unit-Dateien kodiert ist. Nachdem die Symlinks erstellt wurden, wird die
Systemverwalterkonfiguration neu geladen (auf einer zu daemon-reload äquivalenten
Art), um sicherzustellen, dass die Änderungen sofort berücksichtigt werden. Beachten
Sie, dass dies nicht den Effekt hat, dass die freigegebenen Units auch gestartet
werden. Falls dies gewünscht ist, kombinieren Sie den Befehl mit dem Schalter --now
oder rufen Sie später start mit geeigneten Argumenten auf. Beachten Sie, dass bei
der Freigabe von Unit-Instanzen (d.h. Freigabe von Units der Form foo@bar.service)
Symlinks mit dem gleichen Namen wie die erstellten Instanzen im
Unit-Konfigurationsverzeichnis erstellt werden, allerdings zeigen sie auf die
einzelne Vorlagen-Unit-Datei, aus der sie instanziiiert wurden.
Dieser Befehl erwartet entweder gültige Unit-Namen (in diesem Fall werden
verschiedene Unit-Datei-Verzeichnisse automatisch nach Unit-Dateien mit geeigneten
Namen durchsucht) oder absolute Pfade zu Unit-Dateien (in diesem Fall werden die
Dateien direkt eingelesen). Falls eine angegebene Unit-Datei sich außerhalb der
gewöhnlichen Unit-Dateiverzeichnisse befindet, wird ein zusätzlicher Symlink
erstellt, der sie in den Unit-Konfigurationspfad verlinkt, und daher sicherstellt,
dass sie durch Befehle wie start gefunden wird. Das Dateisystem, in dem sich die
verlinkten Unit-Dateien befinden, muss verfügbar sein, wenn Systemd gestartet wird
(z. B. ist alles unterhalb von /home/ oder /var/ nicht erlaubt, außer diese
Verzeichnisse befinden sich auf dem Wurzeldateisystem).
Dieser Befehl wird die ausgeführten Dateisystemaktionen ausgeben. Diese Ausgabe kann
durch Übergabe von --quiet unterdrückt werden.
Beachten Sie, dass diese Aktion nur die in dem Abschnitt »[Install]« der
Unit-Dateien vorgeschlagenen Symlinks erstellt. Obwohl dieser Befehl die empfohlene
Art ist, das Unit-Konfigurationsverzeichnis zu bearbeiten, steht es dem
Administrator frei, manuell zusätzliche Änderungen vorzunehmen, indem er in diesem
Verzeichnis Symlinks anlegt oder entfernt. Dies ist besonders nützlich, um
Konfigurationen zu erstellen, die von den vorgeschlagenen Standardinstallationen
abweichen. In diesem Falle muss der Administrator sicherstellen, daemon-reload wo
notwendig aufzurufen, um sicherzustellen, dass die Änderungen berücksichtigt werden.
Freigeben von Units sollte nicht mit dem Starten (Aktivieren) verwechselt werden,
wie dies durch den Befehl start erfolgt. Freigeben und starten von Units ist
orthogonal: Units können freigegeben sein, ohne gestartet zu sein und gestartet,
ohne freigegeben zu sein. Die Freigabe hängt die Unit an verschiedenen
vorgeschlagenen Stellen ein (beispielsweise so, dass die Unit automatisch beim
Systemstart gestartet wird oder wenn ein bestimmte Art von Hardware eingesteckt
wird). Starten führt den Daemon-Prozess tatsächlich aus (im Falle von Dienste-Units)
oder bindet das Socket (im Falle von Socket-Units) und so weiter.
Abhängig davon ob --system, --user, --runtime oder --global angegeben wurde, gibt
dies die Unit für das System, nur den aufrufenden Benutzer, nur für diesen
Systemstart oder für alle zukünftigen Anmeldungen aller Benutzer frei. Beachten Sie,
dass in letzterem Fall keine Systemd-Daemonkonfiguration neu geladen wird.
Die Verwendung von enable auf maskierten Units wird nicht unterstützt und führt zu
einem Fehler.
- disable UNIT…
Schaltet eine oder mehrere Units aus. Dies entfernt alle Symlinks auf die
Unit-Dateien, die den angegebenen Units aus dem Unit-Konfigurationsverzeichnis
hinterlegt sind und nimmt daher alle durch enable oder link vorgenommenen Änderungen
zurück. Beachten Sie, dass dies alle Symlinks auf passende Unit-Dateien entfernt,
einschließlich manuell erstellter Symlinks, und nicht nur die tatsächlich von enable
oder link erstellten. Beachten Sie, dass zwar disable den Effekt von enable
rückgängig macht, die zwei Befehle aber ansonsten nicht symmetrisch sind, da disable
mehr Symlinks entfernen könnte, als ein vorheriger Aufruf von enable für die gleiche
Unit erstellte.
Dieser Befehl erwartet nur gültige Unit-Namen, er akzeptiert keine Pfade zu
Unit-Dateien.
Zusätzlich zu den als Argument angegebenen Unit-Dateien werden alle Units
ausgeschaltet, die in der in Abschnitt »[Install]« aufgeführten Einstellung Also= in
jeder der Unit-Dateien, auf die agiert wird, enthalten sind.
Dieser Befehl lädt implizit die Systemverwalterkonfiguration nach Abschluss der
Aktion neu. Beachten Sie, dass dieser Befehl die ausgeschalteten Units nicht
implizit stoppt. Falls dies gewünscht ist, kombinieren Sie diesen Befehl entweder
mit dem Schalter --now oder rufen Sie den Befehl stop mit geeigneten Argumenten
später auf.
Dieser Befehl wird Informationen über die ausgeführten Dateisystemaktionen
(Entfernung der Symlinks) ausgeben. Durch Übergabe von --quiet kann diese Ausgabe
unterdrückt werden.
Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine
ähnliche Art wie enable.
- reenable UNIT…
Gibt eine oder mehrere Units erneut frei, wie dies auf der Befehlszeile angegeben
ist. Dies ist eine Kombination von disable und enable und ist nützlich, um die
Symlinks, mit der eine Unit-Datei freigegeben wird, auf die in seinem Abschnitt
»[Install]« konfigurierten Vorgaben zurückzusetzen. Dieser Befehl erwartet nur einen
Unit-Namen und akzeptiert keine Pfade zu Unit-Dateien.
- preset UNIT…
Setzt den Status Freigegeben/Ausgeschaltet einer oder mehrerer Unit-Dateien, wie auf
der Befehlszeile angegeben, auf die in den Voreinstellungsrichtliniendateien
konfigurierten Standardwerte zurück. Dies hat den gleichen Effekt wie disable oder
enable, abhängig davon, wie die Unit in den Voreinstellungsdateien aufgeführt ist.
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet
oder nur freigegeben oder nur ausgeschaltet sein sollen.
Falls die Unit keine Installationsinformationen überträgt, wird sie durch diesen
Befehl ohne Rückmeldung ignoriert. UNIT muss ein echter Unit-Name sein, jeder
Aliasname wird ohne Rückmeldung ignoriert.
Weitere Informationen über das Format der Voreinstellungsrichtlinien finden Sie
unter systemd.preset(5).
- preset-all
Setzt alle installierten Unit-Dateien auf die in der Voreinstellungsrichtliniendatei
konfigurierten Vorgaben zurück (siehe oben).
Verwenden Sie --preset-mode=, um zu steuern, ob Units freigegeben und ausgeschaltet
oder nur freigegeben oder nur ausgeschaltet sein sollen.
- is-enabled UNIT…
Prüft, ob eine der angegebenen Unit-Dateien eingeschaltet ist (wie mit enable).
Liefert einen Exit-Code 0 zurück, falls mindestens eine freigegeben ist, andernfalls
eine von Null verschiedene Zahl. Gibt den derzeitigen Freigabestatus (siehe Tabelle)
aus. Um diese Ausgabe zu unterdrücken, verwenden Sie --quiet. Um Installationsziele
anzuzeigen, verwenden Sie --full.
Tabelle 1. Ausgabe von is-enabled
┌──────────────────┬───────────────────────────┬───────────┐
│Name │ Beschreibung │ Exit-Code │
├──────────────────┼───────────────────────────┼───────────┤
│"enabled" │ Über .wants/, .requires/ │ │
├──────────────────┤ oder Alias=-Symlinks │ │
│"enabled-runtime" │ freigegeben (dauerhaft │ 0 │
│ │ in /etc/systemd/system/ │ │
│ │ oder flüchtig in │ │
│ │ /run/systemd/system/). │ │
├──────────────────┼───────────────────────────┼───────────┤
│"linked" │ Über einen oder mehrere │ │
├──────────────────┤ Symlinks auf die │ │
│"linked-runtime" │ Unit-Datei verfügbar │ │
│ │ gemacht (dauerhaft in │ │
│ │ /etc/systemd/system/ │ │
│ │ oder flüchtig in │ > 0 │
│ │ /run/systemd/system/), │ │
│ │ obwohl die Unit-Datei │ │
│ │ selbst außerhalb des │ │
│ │ Unit-Dateisuchpfades │ │
│ │ liegen kann. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"alias" │ Der Name ist ein Alias │ 0 │
│ │ (Symlink auf eine andere │ │
│ │ Unit-Datei). │ │
├──────────────────┼───────────────────────────┼───────────┤
│"masked" │ Komplett ausgeschaltet, │ │
├──────────────────┤ so dass jede Startaktion │ │
│"masked-runtime" │ darauf fehlschlägt │ │
│ │ (dauerhaft in │ > 0 │
│ │ /etc/systemd/system/ │ │
│ │ oder flüchtig in │ │
│ │ /run/systemd/systemd/). │ │
├──────────────────┼───────────────────────────┼───────────┤
│"static" │ Die Unit-Datei ist nicht │ 0 │
│ │ freigegeben und hat │ │
│ │ keine Vorkehrungen für │ │
│ │ die Freigabe in dem │ │
│ │ Unit-Dateiabschnitt │ │
│ │ »[Install]«. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"indirect" │ Die Unit-Datei selbst │ 0 │
│ │ ist nicht freigegeben, │ │
│ │ hat aber etwas in der │ │
│ │ Einstellung Also= im │ │
│ │ Abschnitt »[Install]« │ │
│ │ der Unit-Datei, wo │ │
│ │ andere Unit-Dateien │ │
│ │ aufgeführt sind, die │ │
│ │ freigegeben werden │ │
│ │ können, oder sie hat │ │
│ │ einen Alias unter einem │ │
│ │ anderen Namen durch │ │
│ │ einen Symlink, der nicht │ │
│ │ auch in Also= angegeben │ │
│ │ ist. Für │ │
│ │ Vorlagen-Unit-Dateien │ │
│ │ ist eine Instanz, die │ │
│ │ sich von der in │ │
│ │ DefaultInstance= │ │
│ │ angegebenen │ │
│ │ unterscheidet, │ │
│ │ freigegeben. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"disabled" │ Die Unit-Datei ist nicht │ > 0 │
│ │ freigegeben, enthält │ │
│ │ aber einen Abschnitt │ │
│ │ »[Install]« mit │ │
│ │ Installationsanweisungen. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"generated" │ Die Unit wurde dynamisch │ 0 │
│ │ mit einem │ │
│ │ Generatorwerkzeug │ │
│ │ erstellt. Siehe │ │
│ │ systemd.generator(7). │ │
│ │ Erstellte Unit-Dateien │ │
│ │ können nicht freigegeben │ │
│ │ werden, sie werden │ │
│ │ implizit durch ihren │ │
│ │ Generator freigegeben. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"transient" │ Die Unit-Datei wurde │ 0 │
│ │ dynamisch mit der │ │
│ │ Laufzeit-API erstellt. │ │
│ │ Flüchtige Units können │ │
│ │ nicht freigegeben werden. │ │
├──────────────────┼───────────────────────────┼───────────┤
│"bad" │ Die Unit-Datei ist │ > 0 │
│ │ ungültig oder ein anderer │ │
│ │ Fehler ist aufgetreten. │ │
│ │ Beachten Sie, dass │ │
│ │ is-enabled diesen Zustand │ │
│ │ nicht tatsächlich │ │
│ │ zurückliefern wird, │ │
│ │ sondern stattdessen eine │ │
│ │ Fehlermeldung ausgeben │ │
│ │ wird. Die durch │ │
│ │ list-unit-files │ │
│ │ dargestellte │ │
│ │ Unit-Datei-Auflistung │ │
│ │ könnte sie allerdings │ │
│ │ enthalten. │ │
└──────────────────┴───────────────────────────┴───────────┘
- mask UNIT…
Blendet eine oder mehrere Units, wie auf der Befehlszeile angegeben, aus. Dies wird
die Unit-Dateien nach /dev/null linken, wodurch sie nicht gestartet werden können.
Dies ist eine stärkere Version von disable, da sie alle Arten von Aktivierung der
Unit verbietet, einschließlich der Freigabe und manueller Aktivierung. Verwenden Sie
diese Option mit Vorsicht. Die Option --runtime wird berücksichtigt, um nur bis zum
nächsten Systemneustart auszublenden. Die Option --now kann verwandt werden, um
sicherzustellen, dass die Units auch gestoppt werden. Dieser Befehl erwartet nur
gültige Unit-Namen, er akzeptiert keine Unit-Dateipfade.
- unmask UNIT…
Blendet eine oder mehrere Unit-Dateien, wie auf der Befehlszeile angegeben, ein.
Dies macht die Wirkung von mask rückgängig. Dieser Befehl erwartet nur gültige
Unit-Namen, er akzeptiert keine Unit-Dateipfade.
- link PFAD…
Linkt eine Unit-Datei, die nicht im Unit-Dateisuchpfad ist, in den Dateisuchpfad.
Dieser Befehl erwartet einen absoluten Pfad zu einer Unit-Datei. Die Wirkung kann
mit disable zurückgenommen werden. Die Wirkung des Befehls besteht darin, dass die
Unit-Datei für Befehle wie start verfügbar gemacht wird, obwohl sie nicht direkt im
Unit-Dateisuchpfad installiert ist. Das Dateisystem, in dem sich die verlinkte
Unit-Datei befindet, muss beim Start von Systemd zugreifbar sein (d.h. alles
unterhalb von /home/ oder /var/ ist nicht erlaubt, außer diese Verzeichnisse
befinden sich im Wurzeldateisystem).
- revert UNIT…
Bringt eine oder mehrere Unit-Dateien auf die Version des Lieferanten zurück. Dieser
Befehl entfernt Ergänzungskonfigurationsdateien, die die angegebene Unit verändern,
sowie alle benutzerkonfigurierten Unit-Dateien, die eine passende, vom Lieferanten
bereitgestellte Unit-Datei außer Kraft setzen. Konkret wird für eine Unit
»foo.service« das passende Verzeichnis »foo.service.d/« mit allen darin enthaltenen
Dateien entfernt, sowohl unterhalb der dauerhaften als auch der
Laufzeitkonfigurationsverzeichnisse (d.h. unterhalb von /etc/systemd/system und
/run/systemd/system). Falls es von der Unit-Datei eine durch den Lieferanten
bereitgestellte Version gibt (d.h. eine Unit-Datei unterhalb von /usr/), werden alle
passenden dauerhaften und Laufzeit-Unit-Dateien, die diese außer Kraft setzen, auch
entfernt. Beachten Sie, dass eine Unit-Datei, für die es keine vom Lieferanten
bereitgestellte Version gibt (d.h. sie wurde nur unterhalb von /etc/systemd/system
oder /run/systemd/system definiert, aber nicht in einer Unit-Datei unterhalb von
/usr/), nicht entfernt wird. Falls eine Unit ausgeblendet ist, wird sie
eingeblendet.
Dieser Befehl kann effektiv dazu verwandt werden, alle mit systemctl edit, systemctl
set-property und systemctl mask vorgenommenen Änderungen zurückzusetzen und alle
ursprünglichen Unit-Dateien mit ihren Einstellungen wieder zur Wirkung zu bringen.
- add-wants ZIEL UNIT…, add-requires ZIELUNIT…
Fügt zu dem ZIEL für eine oder mehrere Units Abhängigkeiten »Wants=« bzw.
»Requires=« hinzu.
Dieser Befehl berücksichtigt --system, --user, --runtime und --global auf eine
ähnliche Art wie enable.
- edit UNIT…
Bearbeitet ein Ergänzungsschnippsel oder eine gesamte Ersetzungsdatei, falls --full
angegeben ist, oder erweitert die angegebene Unit oder setzt sie außer Kraft.
Abhängig davon, ob --system (die Vorgabe), --user, oder --global angegeben ist,
erstellt dieser Befehl für jede Unit eine Ergänzungsdatei, entweder für das System,
für den aufrufenden Benutzer oder für alle zukünftigen Anmeldungen aller Benutzer.
Dann wird der Editor (siehe den Abschnitt »Umgebung« unten) mit temporären Dateien
aufgerufen, die an den wirklichen Ort geschrieben werden, falls der Editor
erfolgreich beendet wird.
Falls --full angegeben ist, wird diese die ursprüngliche Unit kopieren, statt
Ergänzungsdateien zu erstellen.
Falls --force angegeben ist und eine der Units nicht existiert, werden neue
Unit-Dateien für die Bearbeitung geöffnet.
Falls --runtime angegeben ist, wird die Änderung temporär in /run/ vorgenommen und
geht beim nächsten Neustart verloren.
Falls die temporäre Datei beim Beenden leer ist, wird die Änderung der zugehörigen
Unit abgebrochen.
Nachdem die Units bearbeitet wurden, wird die Systemd-Konfiguration neu geladen (auf
eine Art, die äquivalent zu daemon-reload ist).
Beachten Sie, dass dieser Befehl nicht zur Bearbeitung ferner Units verwandt werden
kann und dass Sie keine Units, die in /etc/ liegen, temporär bearbeiten können, da
diese vor /run/ Vorrang haben.
- get-default
Liefert das Standardziel, in welches der Systemstart erfolgt, zurück. Dies liefert
den Ziel-Unit-Namen, auf das der Alias (Symlink) von default.target zeigt.
- set-default ZIEL
Setzt das Vorgabeziel, in das der Systemstart erfolgen soll. Dies setzt (als
Symlink) den default.target-Alias auf die angegebene Ziel-Unit.
Maschinenbefehle
- list-machines [MUSTER…]
Listet den Rechner und alle laufenden Container mit ihren Zuständen auf. Falls eines
oder mehrere MUSTER angegeben sind, werden nur auf die Muster passende Container
angezeigt.
Auftragsbefehle
- list-jobs [MUSTER…]
Listet laufende Aufträge auf. Falls eines oder mehrere MUSTER angegeben sind, werden
nur Aufträge von Units, die auf die Muster passen, angezeigt.
Wird dies mit --after oder --before kombiniert, wird die Liste mit Informationen
darüber angereichert, auf welchen anderen Auftrag jeder Auftrag wartet und welche
anderen Aufträge auf ihn warten, siehe oben.
- cancel AUFTRAG…
Bricht einen oder mehrere auf der Befehlszeile durch ihre numerische Auftragskennung
angegebene Aufträge ab. Falls keine Auftragskennung angegeben ist, werden alle
wartenden Aufträge abgebrochen.
Umgebungsbefehle
systemd unterstützt einen Umgebungsblock, der an vom Systemverwalter erzeugte Prozesse übergeben wird. Die Namen der Variablen können ASCII-Buchstaben, Ziffern und das Unterstrichzeichen enthalten. Variablennamen dürfen nicht leer sein oder mit einer Ziffer starten. In den Variablenwerten sind die meisten Zeichen erlaubt, aber die gesamte Sequenz muss gültiges UTF-8 sein. (Beachten Sie, dass Steuerzeichen wie der Zeilenumbruch (NL), der Tabulator (TAB) oder das Maskierzeichen (ESC) gültiges ASCII und damit gültiges UTF-8 sind). Die Gesamtlänge des Umgebungsblocks ist auf den Wert _SC_ARG_MAX, der in sysconf(3) definiert ist, begrenzt.
- show-environment
Zeigt den Umgebungsblock des Systemd-Verwalters an. Dies ist der Umgebungsblock, der
an alle vom Verwalter erzeugten Prozesse übergeben wird. Der Umgebungsblock wird in
einer direkten Form, geeignet für die Einbindung in die meisten Shells, ausgegeben.
Falls in den Variablenwerten keine besonderen Zeichen oder Leerraumzeichen enthalten
sind, erfolgt keine Maskierung und die Zuweisungen haben die Form »VARIABLE=Wert«.
Falls Leerraumzeichen oder Zeichen, die für die Shell eine besondere Bedeutung
haben, vorhanden sind, wird Dollar-Einzelanführungszeichen-Maskierung verwandt und
die Zuweisungen haben die Form »VARIABLE=$'Wert'«. Diese Syntax wird bekanntermaßen
von bash(1), zsh(1), ksh(1) und der busybox(1)-ash(1), aber nicht von dash(1) und
fish(1) unterstützt.
- set-environment VARIABLE=WERT…
Setzt eine oder mehrere Systemd-Verwalter-Umgebungsvariablen, wie auf der
Befehlszeile angegeben. Dieser Befehl wird fehlschlagen, falls die Variablennamen
und -werte nicht den vorher beschriebenen Regeln folgen.
- unset-environment VARIABLE…
Setzt eine oder mehrere Umgebungsvariablen des Systemd-Verwalters zurück. Falls nur
ein Variablenname angegeben ist, wird er unabhängig von seinem Wert entfernt. Falls
eine Variable und ein Wert angegeben werden, wird die Variable nur entfernt, falls
sie den angegebenen Wert hat.
- import-environment VARIABLE…
Importiert alle, eine oder mehrere Umgebungsvariablen, die auf dem Client gesetzt
sind, in den Umgebungsblock des Systemd-Verwalters. Falls eine Liste mit einer oder
mehrerer Umgebungsvariablennamen übergeben wird, werden deren Wert auf der
Client-Seite dann in den Umgebungsblock des Verwalters importiert. Falls Namen davon
keine gültigen Umgebungsvariablen sind oder gemäß der oben beschriebenen Regeln
ungültige Werte haben, wird ein Fehler ausgelöst. Falls keine Argumente übergeben
werden, wird der gesamte, vom Prozess systemctl geerbte Umgebungsblock importiert.
In diesem Modus werden alle geerbten und ungültigen Variablen stillschweigend
ignoriert.
Der Import des vollständigen ererbten Umgebungsblocks (der Aufruf dieses Befehls
ohne Argumente) ist als veraltet markiert. Eine Shell setzt Dutzende von Variablen,
die nur lokal Sinn ergeben und nur für Prozesse gedacht sind, die Abkömmlinge der
Shell sind. Solche Variablen sind im globalen Umgebungsblock für andere Prozesse
verwirrend.
Zustandsbefehle für den Verwalter
- daemon-reload
Lädt die Systemverwalterkonfiguration neu. Dies wird alle Generatoren neu ausführen
(siehe systemd.generator(7)), alle Unit-Dateien neu laden und den gesamten
Abhängigkeitsbaum neu erstellen. Während der Daemon neu geladen wird, bleiben
sämtliche Sockets, an denen Systemd aufgrund von Benutzerkonfiguration auf Anfragen
wartet, erreichbar.
Dieser Befehl sollte nicht mit dem Befehl reload durcheinandergebracht werden.
- daemon-reexec
Führt den Systemd-Verwalter neu aus. Dies wird den Verwalterzustand serialisieren,
die Prozesse neu ausführen und den Zustand wieder deserialisieren. Dieser Befehl ist
eigentlich nur für die Fehlersuche und Paket-Upgrades geeignet. Manchmal mag er für
schwergewichtige daemon-reload hilfreich sein. Während der Daemon neu ausgeführt
wird, bleiben sämtliche Sockets, an denen Systemd aufgrund von Benutzerkonfiguration
auf Anfragen wartet, erreichbar.
- log-level [STUFE]
Zeigt die aktuelle Protokollierstufe des Verwalters an, falls kein Argument
angegeben ist. Falls das optionale Argument STUFE bereitgestellt wird, dann ändert
der Befehl die aktuelle Protokollierstufe des Verwalters auf STUFE (akzeptiert die
gleichen Werte wie für das in systemd(1) beschriebene --log-level=).
- log-target [ZIEL]
Zeigt das aktuelle Protokollierziel des Verwalters an, falls kein Argument angegeben
ist. Falls das optionale Argument ZIEL bereitgestellt wird, dann ändert der Befehl
das aktuelle Protokollierziel des Verwalters auf ZIEL (akzeptiert die gleichen Werte
wie für das in systemd(1) beschriebene --log-target=).
- service-watchdogs [yes|no]
Zeigt den aktuellen Zustand des Laufzeitdienste-Watchdogs an, falls kein Argument
angegeben ist. Falls ein optionales logisches Argument bereitgestellt wird, werden
die globalen Laufzeitdienste-Watchdogs (WatchdogSec=) und Notfallaktionen (z. B.
OnFailure= oder StartLimitAction=) aktiviert oder deaktiviert; siehe
systemd.service(5). Der Hardware-Watchdog ist von dieser Einstellung nicht
betroffen.
Systembefehle
- is-system-running
Prüft, ob das System einsatzfähig ist. Dies liefert Erfolg (Exit-Code 0) zurück,
wenn das System komplett hochgefahren und im Betrieb und insbesondere nicht beim
Hochfahren, beim Herunterfahren oder im Wartungsmodus ist und wenn keine Dienste
fehlgeschlagen sind. Ansonsten wird ein Fehlschlag zurückgeliefert (Exit-Code ist
nicht null). Zusätzlich wird der aktuelle Zustand in einer kurzen Zeichenkette auf
der Standardausgabe ausgegeben, siehe nachfolgende Tabelle. Verwenden Sie --quiet
zum Unterdrücken dieser Ausgabe.
Verwenden Sie --wait, um darauf zu warten, dass der Systemstartprozess abgeschlossen
ist, bevor der aktuelle Zustand angezeigt und der angemessene Fehlerstatus
zurückgeliefert wird. Falls --wait in Verwendung ist, werden die Zustände
initializing oder starting nicht gemeldet, stattdessen wird der Befehl blockieren,
bis ein späterer Zustand (wie running oder degraded) erreicht ist.
Tabelle 2. Ausgabe von is-system-running
┌─────────────┬──────────────────────────┬───────────┐
│Name │ Beschreibung │ Exit-Code │
├─────────────┼──────────────────────────┼───────────┤
│initializing │ Früher Systemstart, vor │ > 0 │
│ │ basic.target erreicht │ │
│ │ oder der Wartungs- │ │
│ │ Zustand betreten wurde. │ │
├─────────────┼──────────────────────────┼───────────┤
│starting │ Späte Startphase, bevor │ > 0 │
│ │ die │ │
│ │ Auftragswarteschlange │ │
│ │ erstmalig in den │ │
│ │ Leerlauf geht oder eines │ │
│ │ der Rettungsziele │ │
│ │ erreicht wird. │ │
├─────────────┼──────────────────────────┼───────────┤
│running │ Das System ist komplett │ 0 │
│ │ betriebsbereit. │ │
├─────────────┼──────────────────────────┼───────────┤
│degraded │ Das System ist │ > 0 │
│ │ betriebsbereit, aber │ │
│ │ eine oder mehrere Units │ │
│ │ sind fehlgeschlagen. │ │
├─────────────┼──────────────────────────┼───────────┤
│maintenance │ Das Rettungs- oder │ > 0 │
│ │ Notfallziel ist aktiv. │ │
├─────────────┼──────────────────────────┼───────────┤
│stopping │ Der Verwalter fährt sich │ > 0 │
│ │ herunter. │ │
├─────────────┼──────────────────────────┼───────────┤
│offline │ Der Verwalter läuft │ > 0 │
│ │ nicht. Insbesondere ist │ │
│ │ dies der │ │
│ │ Betriebszustand, falls │ │
│ │ ein inkompatibles │ │
│ │ Programm als │ │
│ │ Systemverwalter (PID 1) │ │
│ │ läuft. │ │
├─────────────┼──────────────────────────┼───────────┤
│unknown │ Der Betriebszustand │ > 0 │
│ │ konnte aufgrund von │ │
│ │ fehlenden Ressourcen │ │
│ │ oder einer anderen │ │
│ │ Fehlerursache nicht │ │
│ │ bestimmt werden. │ │
└─────────────┴──────────────────────────┴───────────┘
- default
Betritt den Standardmodus. Dies ist zu systemctl isolate default.target äquivalent.
Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
Verhalten.
- rescue
Betritt den Rettungsmodus. Dies ist zu systemctl isolate rescue.target äquivalent.
Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
Verhalten.
- emergency
Betritt den Notfallmodus. Dies ist zu systemctl isolate emergency.target äquivalent.
Diese Aktion blockiert standardmäßig, verwenden Sie --no-block für asynchrones
Verhalten.
- halt
Fährt das System herunter und hält es an. Dies ist größtenteils äquivalent zu
systemctl start halt.target --job-mode=replace-irreversibly --no-block, gibt aber
auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist asynchron; er wird
zurückkehren, nachdem die Halt-Aktion in die Warteschlange eingereiht ist, ohne
darauf zu warten, dass er abgeschlossen ist. Beachten Sie, dass diese Aktion einfach
den Betriebssystemkernel nach dem Herunterfahren anhalten wird, die Hardware
verbleibt eingeschaltet. Verwenden Sie systemctl poweroff, um das System
auszuschalten (siehe unten).
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden Dienste
übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
oder nur lesbar eingehängt, sofort danach erfolgt das Anhalten des Systems. Falls
--force zweimal angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu Datenverlust
führen. Beachten Sie, dass die Halt-Aktion von systemctl selbst ausgeführt wird,
wenn --force zweimal angegeben wird und der Systemverwalter dann nicht kontaktiert
wird. Dies bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der
Systemverwalter abgestürzt ist.
- poweroff
Fährt das System herunter und schaltet es aus. Dies ist größtenteils zu systemctl
start poweroff.target --job-mode=replace-irreversibly --no-block äquivalent, gibt
aber auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist asynchron; er
wird zurückkehren, nachdem die Ausschalt-Aktion in die Warteschlange eingereiht ist,
ohne darauf zu warten, dass er abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden Dienste
übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
oder nur lesbar eingehängt, sofort danach erfolgt das Ausschalten des Systems. Falls
--force zweimal angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu Datenverlust
führen. Beachten Sie, dass die Ausschalt-Aktion von systemctl selbst ausgeführt
wird, wenn --force zweimal angegeben wird und der Systemverwalter dann nicht
kontaktiert wird. Dies bedeutet, dass der Befehl selbst dann erfolgreich sein
sollte, wenn der Systemverwalter abgestürzt ist.
- reboot
Fährt das System herunter und startet es neu. Dies ist größtenteils zu systemctl
start reboot.target --job-mode=replace-irreversibly --no-block äquivalent, gibt aber
auch eine Wall-Nachricht an alle Benutzer aus. Dieser Befehl ist asynchron; er wird
zurückkehren, nachdem die Neustart-Aktion in die Warteschlange eingereiht ist, ohne
darauf zu warten, dass er abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden Dienste
übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
oder nur lesbar eingehängt, sofort danach erfolgt der Neustart des Systems. Falls
--force zweimal angegeben ist, wird die Aktion sofort ausgeführt, ohne irgendeinen
Prozess zu beenden oder ein Dateisystem auszuhängen. Dies kann zu Datenverlust
führen. Beachten Sie, dass die Neustart-Aktion von systemctl selbst ausgeführt wird,
wenn --force zweimal angegeben wird und der Systemverwalter dann nicht kontaktiert
wird. Dies bedeutet, dass der Befehl selbst dann erfolgreich sein sollte, wenn der
Systemverwalter abgestürzt ist.
Falls der Schalter --reboot-argument= angegeben ist, wird er als optionales Argument
an den Systemaufruf reboot(2) übergeben.
- kexec
Fährt das System herunter und startet mit kexec neu. Dies ist zu systemctl start
kexec.target --job-mode=replace-irreversibly --no-block äquivalent. Dieser Befehl
ist asynchron; er wird zurückkehren, nachdem die Neustart-Aktion in die
Warteschlange eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Falls mit --force kombiniert, wird das Herunterfahren aller laufenden Dienste
übersprungen, alle Prozesse werden aber getötet und alle Dateisysteme ausgehängt
oder nur lesbar eingehängt, sofort danach erfolgt der Neustart des Systems.
- exit [EXIT-CODE]
Bittet den Diensteverwalter, sich zu beenden. Dies wird nur für
Benutzerdiensteverwalter (d.h. im Zusammenspiel mit der Option --user) oder in
Containern unterstützt und ist andernfalls zu poweroff äquivalent. Dieser Befehl ist
asynchron; er wird zurückkehren, nachdem die Beende-Aktion in die Warteschlange
eingereiht ist, ohne darauf zu warten, dass er abgeschlossen ist.
Falls EXIT_CODE übergeben wurde, wird sich der Diensteverwalter mit dem angegebenen
Exit-Code beenden.
- switch-root WURZEL [INIT]
Schaltet auf ein anderes Wurzelverzeichnis und führt darunter einen neuen
Systemverwalter aus. Dies ist für den Einsatz in anfänglichen RAM-Platten (»initrd«)
gedacht und wird vom Systemverwalter der Initrd (d.h. dem »Init«-Prozess) auf dem
Hauptsystemverwalterprozess wechseln, der vom tatsächlichen Datenträger des Rechners
geladen wird. Dieser Aufruf akzeptiert zwei Argumente: das Verzeichnis, das das neue
Wurzelverzeichnis werden soll und der Pfad des neuen Systemverwalterprogramms
darunter, das als PID 1 ausgeführt werden soll. Falls letzterer nicht angegeben wird
oder die leere Zeichenkette ist, wird automatisch nach einem Systemd-Programm
gesucht und dieses als Init verwandt/. Falls der Systemverwalterpfad nicht angegeben
wird, der leeren Zeichenkette gleicht oder identisch zu dem Pfad zu dem
Systemdprogramm ist, wird der Zustand des Systemverwalterprozesses der Initrd an den
Hauptsystemverwalter übergeben, womit Letzterem eine Selbstüberprüfung des Zustands
der in der Initird-Systemstartphase beteiligten Dienste ermöglicht wird.
- suspend
Suspendiert das System. Dies wird die Aktivierung der besonderen Ziel-Unit
suspend.target auslösen. Dieser Befehl ist asynchron; er wird zurückkehren, nachdem
die Suspendier-Aktion erfolgreich in die Warteschlange eingereiht ist. Er wird nicht
darauf warten, dass der Suspendier-/Wiederaufnahmezyklus abgeschlossen ist.
- hibernate
Bringt das System in den Ruhezustand. Dies wird die Aktivierung der besonderen
Ziel-Unit hibernate.target auslösen. Dieser Befehl ist asynchron; er wird
zurückkehren, nachdem die Ruhezustandsaktion erfolgreich in die Warteschlange
eingereiht ist. Er wird nicht darauf warten, dass der
Ruhezustand-/Wiederaufwachzyklus abgeschlossen ist.
- hybrid-sleep
Bringt das System in den Ruhezustand und suspendiert es. Dies wird die Aktivierung
der besonderen Ziel-Unit hybrid-sleep.target auslösen. Dieser Befehl ist asynchron;
er wird zurückkehren, nachdem die hybride Schlafaktion erfolgreich in die
Warteschlange eingereiht ist. Er wird nicht darauf warten, dass der
Schlaf-/Wiederaufwachzyklus abgeschlossen ist.
- suspend-then-hibernate
Suspendiert das System nach einer in systemd-sleep.conf angegebenen Verzögerung und
bringt es in den Ruhezustand. Dies wird die Aktivierung der besonderen Ziel-Unit
suspend-then-hibernate.target auslösen. Dieser Befehl ist asynchron; er wird
zurückkehren, nachdem die hybride Schlafaktion erfolgreich in die Warteschlange
eingereiht ist. Er wird nicht darauf warten, dass der Schlaf-/Wiederaufwachzyklus
oder Ruhezustand-/Wiederaufwachzyklus abgeschlossen ist.
Parametersyntax
Die oben aufgeführten Unit-Befehle akzeptieren entweder einen einzelnen Unit-Namen (als UNIT bezeichnet) oder mehrere Unit-Angaben (als MUSTER … bezeichnet). Im ersten Fall muss der Unit-Name mit oder ohne Endung angegeben werden. Falls die Endung nicht angegeben ist (der Unit-Name »abgekürzt« wurde), wird Systemctl eine geeignete Endung anhängen, standardmäßig ».service«, und typabhängige Endungen im Falle von Befehlen, die nur auf bestimmte Unit-Typen agieren. Beispielsweise sind
# systemctl start sshd
und
# systemctl start sshd.service
äquivalent, wie auch
# systemctl isolate default
und
# systemctl isolate default.target
Beachten Sie, dass der (absolute) Pfad zu den Geräteknoten automatisch in einen Geräte-Unit-Namen und andere (absolute) Pfade zu Einhänge-Unit-Namen umgewandelt werden.
# systemctl status /dev/sda
# systemctl status /home
ist äquivalent zu:
# systemctl status dev-sda.device
# systemctl status home.mount
Im zweiten Fall werden Shell-artige Globs mit den primären Namen aller derzeit im Speicher befindlichen Units abgeglichen; wörtliche Unit-Namen, mit oder ohne eine Endung, werden wie im ersten Fall behandelt. Das bedeutet, dass sich wörtliche Unit-Namen immer auf genau eine Unit beziehen, aber Globs auf null Units passen können, was nicht als Fehler betrachtet wird.
Glob-Muster verwenden fnmatch(3), daher werden normale Shell-artige Glob-Regeln verwandt und »*«, »?« und »[]« dürfen verwendet werden. Siehe glob(7) für weitere Details. Die Muster werden mit den primären Namen der derzeit im Speicher befindlichen Units verglichen und Muster, die auf nichts passen, werden ohne Rückmeldung übersprungen. Beispielsweise wird
# systemctl stop sshd@*.service
alle sshd@.service-Instanzen stoppen. Beachten Sie, dass Aliasnamen von Units und Units, die sich nicht im Speicher befinden, für die Glob-Erweiterung nicht berücksichtigt werden.
Für Unit-Dateibefehle sollte die angegebene UNIT der Name der Unit-Datei (möglicherweise abgekürzt, siehe oben) oder der absolute Pfad zu der Unit-Datei sein:
# systemctl enable foo.service
oder
# systemctl link /path/to/foo.service
OPTIONEN
Die folgenden Optionen werden verstanden:
-t, --type=
Dieses Argument sollte eine Kommata-getrennte Liste von Unit-Typen wie service und
socket sein.
Begrenzt die Anzeige auf bestimmte Unit-Typen, wenn Units aufgelistet werden, falls
eines der Argumente ein Unit-Typ ist. Andernfalls werden alle Typen angezeigt.
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm
beendet sich, falls eines der Argumente help ist.
--state=
Das Argument sollte eine Kommata-getrennte Liste von Zuständen LOAD, SUB oder ACTIVE
sein. Zeigt nur die Units in den angegebenen Zuständen an, wenn diese aufgelistet
werden. Verwenden Sie --state=failed, um nur fehlgeschlagene Units anzuzeigen.
Als Spezialfall wird eine Liste der erlaubten Werte angezeigt und das Programm
beendet sich, falls eines der Argumente help ist.
-p, --property=
Begrenzt die Anzeige auf die angegebenen Eigenschaften bei der Anzeige der
Eigenschaften von Units/Aufträgen/Verwalter mit dem Befehl show. Das Argument sollte
eine Kommata-getrennte Liste von Eigenschaftsnamen wie »MainPID« sein. Falls nicht
angegeben, werden alle bekannten Eigenschaften angezeigt. Falls mehr als einmal
angegeben, werden alle Eigenschaften mit den angegebenen Namen angezeigt. Für
Eigenschaftsnamen ist die Shell-Vervollständigung implementiert.
Für den Verwalter selbst wird systemctl show alle verfügbaren Eigenschaften
anzeigen. Die meisten davon sind von den in systemd-system.conf(5) beschriebenen
Optionen abgeleitet oder stimmen eng mit ihnen überein.
Eigenschaften für Units unterscheiden sich zwischen Unit-Typen, daher ist die
Anzeige einer Unit (selbst einer nicht vorhandenen) ein Weg, um die Eigenschaften,
die diese Unit betreffen, aufzulisten. Ähnlich wird die Anzeige eines Auftrags die
allen Aufträgen zugehörigen Eigenschaften auflisten. Eigenschaften für Units sind in
systemd.unit(5) und den Seiten für die individuellen Unit-Typen systemd.service(5),
systemd.socket(5) usw. dokumentiert.
-P
Äquivalent zu --value --property=, d.h. zeigt den Wert der Eigenschaft ohne den
Eigenschaftsnamen und »=«. Beachten Sie, dass die einmalige Verwendung von -P auch
die mit -p/--property= aufgeführten Eigenschaften betrifft.
-a, --all
Zeigt beim Auflisten von Units mit list-units auch inaktive Units und Units, die
anderen Units folgen, an. Bei der Anzeige der Eigenschaften von
Units/Aufträgen/Verwaltern werden alle Eigenschaften angezeigt, unabhängig davon, ob
sie gesetzt sind oder nicht.
Um alle im Dateisystem installierten Units aufzulisten, verwenden Sie stattdessen
den Befehl list-unit-files.
Zeigt beim Auflisten von Units mit list-dependencies alle abhängigen Units rekursiv
an (standardmäßig werden nur Abhängigkeiten von Ziel-Units angezeigt).
Zeigt bei der Verwendung mit status Journal-Nachrichten vollständig an, selbst falls
sie nicht darstellbaren Zeichen enthalten oder sehr lang sind. Standardmäßig werden
Felder mit nicht darstellbaren Zeichen als »blob data« abgekürzt«. (Beachten Sie,
dass das Textanzeigeprogramm die nicht darstellbaren Zeichen wieder maskieren
könnte.)
-r, --recursive
Beim Auflisten von Units werden auch Units von lokalen Containern angezeigt. Units
von lokalen Containern wird der Container-Name vorangestellt, getrennt durch einen
einzelnen Doppelpunkt (»:«).
--reverse
Zeigt mit list-dependencies inverse Abhängigkeiten an, d.h. folgt Abhängigkeiten vom
Typ WantedBy=, RequiredBy=, PartOf=, BoundBy= statt Wants= und ähnlichen.
--after
Zeigt mit list-dependencies Units an, die vor der angegebenen Unit angeordnet sind.
Mit anderen Worten, listet rekursiv Units, die der Abhängigkeit After= folgen, auf.
Beachten Sie, dass jede Abhängigkeit After= automatisch gespiegelt wird, um eine
Abhängigkeit Before= zu erstellen. Temporäre Abhängigkeiten können explizit
angegeben werden, werden aber auch implizit für Units mit den Zielen WantedBy=
(siehe systemd.target(5)) und als Ergebnis von anderen Anweisungen (beispielsweise
RequiresMountsFor=) erstellt. Sowohl explizit als auch implizit eingeführte
Abhängigkeiten werden mit list-dependencies angezeigt.
Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag
angezeigt, welche anderen Aufträge auf ihn warten. Kann mit --before kombiniert
werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle
Aufträge, auf die jeder Auftrag wartet anzuzeigen.
--before
Zeigt mit list-dependencies Units an, die nach der angegebenen Unit angeordnet sind.
Mit anderen Worten, listet rekursiv Units, die der Abhängigkeit Before= folgen, auf.
Bei der Übergabe an den Befehl list-jobs wird für jeden dargestellten Auftrag
angezeigt, auf welche anderen Aufträge er wartet. Kann mit --after kombiniert
werden, um sowohl die Aufträge, die auf jeden Auftrag warten, als auch alle
Aufträge, auf die jeder Auftrag wartet anzuzeigen.
--with-dependencies
Bei der Verwendung mit status, cat, list-units und list-unit-files geben diese
Befehle alle angegebenen Units und die Abhängigkeiten von diesen Units aus.
Die Optionen --reverse, --after, --before können zur Änderung, welche
Abhängigkeitsarten gezeigt werden, verwandt werden.
-l, --full
Verkürzt Unit-Namen, Prozessbaumeinträge, Journal-Ausgabe nicht und schneidet
Unit-Beschreibungen in der Ausgabe von status, list-units, list-jobs und list-timers
nicht ab.
Zeigt auch Installationsziele in der Ausgabe von is-enabled an.
--value
Zeigt bei der Ausgabe der Eigenschaften mit show nur den Wert an, der
Eigenschaftsname und das »=« wird übersprungen. Siehe auch obige Option -P.
--show-types
Zeigt bei der Anzeige von Sockets auch den Typ des Sockets an.
--job-mode=
Beim Einstellen eines Auftrags in die Warteschlangen steuert diese Option, wie mit
bereits in der Warteschlange befindlichen Aufträgen umgegangen werden soll. Sie
akzeptiert entweder »fail«, »replace«, »replace-irreversibly«, »isolate«,
»ignore-dependencies«, »ignore-requirements«, »flush« oder »triggering«.
Standardmäßig »replace«, außer wenn der Befehl isolate verwandt wird, da dieser den
Auftragsmodus »isolate« impliziert.
Falls »fail« angegeben ist und die angeforderte Aktion in Konflikt mit einem
anhängigen Auftrag steht (genauer: dazu führt, dass ein anhängiger Auftrag in einen
Stopp-Auftrag oder umgedreht umgewandelt wird), wird die Aktion fehlschlagen.
Falls (die Vorgabe) »replace« angegeben ist, wird jeder in Konflikt stehende
anhängige Auftrag falls notwendig ersetzt.
Falls »replace-irreversibly« angegeben ist, wird wie bei »replace« agiert, aber die
neuen Aufträge als unumkehrbar markiert. Dies hindert zukünftige in Konflikt
stehende Transaktionen daran, diese Aufträge zu ersetzen (oder sie selbst daran, in
die Warteschlange aufgenommen zu werden, während die irreveresiblen Aufträge noch
anhängig sind). Irreversible Aufträge können weiterhin mit dem Befehl cancel
abgebrochen werden. Dieser Auftragmodus sollte bei jeder Transaktion, die
shutdown.target hereinzieht, verwandt werden.
»isolate« ist nur für Startaktionen gültig und führt dazu, dass alle anderen Units
beendet werden, wenn die angegebene Unit gestartet wird. Dieser Modus wird immer
verwandt, wenn der Befehl isolate verwandt wird.
»flush« führt dazu, dass alle Aufträge in der Warteschlange abgebrochen werden, wenn
der neue Auftrag in die Warteschlange eingestellt wird.
Falls »ignore-dependencies« angegeben ist, werden alle Unit-Abhängigkeiten für
diesen neuen Auftrag ignoriert und die Aktion wird sofort ausgeführt. Falls
übergeben, werden keine für die Unit benötigten Units hereingezogen und keine
Ordnungsabhängigkeiten berücksichtigt. Dies dient hauptsächlich der Fehlersuche und
als Rettungswerkzeug für den Administrator und sollte von Anwendungen nicht verwandt
werden.
»ignore-requirements« ist ähnlich zu »ignore-dependencies«, führt aber nur dazu,
dass die Voraussetzungsabhängigkeiten ignoriert werden, die Ordnungsabhängigkeiten
werden weiterhin respektiert.
»triggering« kann nur mit systemctl stop verwandt werden. In diesem Modus wird die
angegebene Unit und alle aktiven Units, die es auslöst, gestoppt. Siehe die
Diskussion von Triggers= in systemd.unit(5) für weitere Informationen über
auslösende Units.
-T, --show-transaction
Zeigt eine knappe Information über alle Aufträge in der Warteschlange an, wenn eine
Unit in die Warteschlange gestellt wird (beispielsweise als Auswirkung des Aufrufs
systemctl start oder ähnlichem). Dabei werden sowohl die angeforderten Aufträge als
auch alle aufgrund von Unit-Abhängigkeiten hinzugefügte berücksichtigt. Beachten
Sie, dass die Ausgabe nur Aufträge enthalten wird, die sofort Teil der angeforderten
Transaktion sind. Es ist möglich, dass die Ausführung des Programmcodes des Dienstes
zum Hochfahren die Auswirkung hat, dass die angeforderten Aufträge dass Hereinziehen
weiterer Aufträge anfordern. Das bedeutet, dass beim Abschluss der angezeigten
Aufträge letztendlich mehr Aufträge als die angezeigten enthalten sein könnten.
--fail
Kurzform von --job-mode=fail.
Wird dies mit dem Befehl kill zusammen verwandt, wird die Aktion zu einem Fehler
führen, falls keine Units getötet wurden.
--check-inhibitors=
Diese Option steuert, wie mit Unterdrückungssperren umgegangen werden soll, wenn das
Herunterfahren oder der Schlafzustand erbeten wurde. Sie akzeptiert entweder »auto«,
»yes« oder »no«. Standardmäßig »auto«, das sich wie »yes« für interaktive Aufrufe
(d.h. von einem TTY) und wie »no« für nicht interaktive Aufrufe verhalten wird.
»yes« ermöglicht es, dass die Anfrage Unterdrückungssperren berücksichtigt. »no«
führt dazu, dass die Anfrage Unterdrückungssperren ignoriert.
Anwendungen können Unterdrückungssperren einrichten, um zu vermeiden, dass bestimmte
wichtige Aktionen (wie das Brennen von CDs oder ähnlichem) durch das Herunterfahren
des Systems oder Schlafzustände unterbrochen werden. Jeder Benutzer kann diese
Sperren erlangen und privilegierte Benutzer dürfen diese Sperren außer Kraft setzen.
Falls irgendwelche Sperren erlangt wurden, werden Anfragen zum Herunterfahren oder
für Schlafzustände normalerweise fehlschlagen (außer sie sind privilegiert) und eine
Liste der aktiven Sperren wird ausgegeben. Falls allerdings »no« oder »auto« bei
nicht interaktiven Anfragen angegeben wurde, werden die etablierten Sperren
ignoriert und nicht angezeigt und die Aktion wird dennoch versucht, wobei
möglicherweise zusätzliche Privilegien benötigt werden. Kann durch --force außer
Kraft gesetzt werden.
-i
Kurzform für --check-inhibitors=no.
--dry-run
Gibt einfach aus, was getan würde. Momentan von den Unterbefehlen halt, poweroff,
reboot, kexec, suspend, hibernate, hybrid-sleep, suspend-then-hibernate, default,
rescue, emergency und exit unterstützt.
-q, --quiet
Unterdrückt die Ausgabe des Ergebnisses der verschiedenen Befehle und auch die
Hinweise auf abgeschnittene Protokollzeilen. Dies unterdrückt nicht die Ausgabe von
Befehlen, für die die dargestellte Ausgabe das einzige Ergebnis ist (wie show).
Fehler werden immer ausgegeben.
--no-block
Wartet nicht synchron darauf, dass die angefragte Aktion sich beendet. Falls dies
nicht angegeben ist, wird der Auftrag überprüft, in die Warteschlange eingereiht und
systemctl wartet, bis das Hochfahren der Unit abgeschlossen ist. Durch Übergabe
dieses Arguments wird nur überprüft und in die Warteschlange eingereiht. Diese
Option darf nicht mit --wait kombiniert werden.
--wait
Wartet synchron darauf, dass gestartete Units sich wieder beenden. Diese Option darf
nicht mit --no-block kombiniert werden. Beachten Sie, dass dies ewig warten wird,
falls eine übergebene Unit sich nie beendet (entweder selbst oder explizit gestoppt
wird); insbesondere Dienste, die »RemainAfterExit=yes« verwenden.
Wird dies zusammen mit is-system-running verwandt, wird gewartet, bis der
Systemstartprozess abgeschlossen ist, bevor zurückgekehrt wird.
--user
Kommuniziert mit dem Diensteverwalter des aufrufenden Benutzers statt mit dem
Diensteverwalter des Systems.
--system
Kommuniziert mit dem Diensteverwalter des Systems. Dies ist die implizite Vorgabe.
--failed
Listet Units im fehlgeschlagenen Zustand auf. Dies ist zu --state=failed äquivalent.
--no-wall
Versendet keine Wall-Nachrichten vor halt, power-off und reboot.
--global
Agiert im globalen Benutzerverzeichnis, falls mit enable und disable verwandt, und
gibt somit eine Unit-Datei global für alle zukünftigen Anmeldungen aller Benutzer
frei oder schaltetet sie aus.
--no-reload
Lädt Daemon-Konfiguration nach der Ausführung der Änderung nicht implizit neu, falls
mit enable und disable verwandt.
--no-ask-password
Deaktiviert bei der Verwendung mit start und verwandten Befehlen Fragen nach
Passwörtern. Hintergrunddienste können die Eingabe von Passwörtern oder
Passphrasenzeichenketten benötigten, beispielsweise um Systemfestplatten oder
kryptographische Zertifikate zu entsperren. Außer wenn diese Option angegeben ist
und der Befehl von einem Terminal aus ausgeführt wird, wird systemctl den Benutzer
auf dem Terminal nach den notwendigen Geheimnissen fragen. Verwenden Sie diesen
Schalter, um das Verhalten abzuschalten. In diesem Fall muss das Passwort über einen
anderen Weg bereitgestellt werden (beispielsweise graphische Passsworte-Agenten)
oder der Service könnte fehlschlagen. Dies deaktiviert auch die Abfrage des
Benutzers für die Authentifizierung für privilegierte Aktionen.
--kill-who=
Bei der Verwendung mit kill wählen Sie aus, welchen Prozessen ein Signal gesandt
werden soll. Muss einer aus main, control und all sein, um auszuwählen, ob nur der
Hauptprozess, der Steuerprozess oder alle Prozess der Unit getötet werden soll(en).
Der Hauptprozess der Unit ist derjenige, der die Lebensdauer bestimmt. Ein
Steuerprozess einer Unit ist derjenige, der durch den Verwalter aufgerufen wird, um
Statusänderungen zu veranlassen. Beispielsweise sind alle Prozesse, die aufgrund von
ExecStartPre=-, ExecStop=- oder ExecReload=-Einstellungen von Dienste-Units
gestartet werden, Steuerprozesse. Beachten Sie, dass es für jeden Zeitpunkt nur
einen Steuerprozess pro Unit gibt, da nur eine Statusänderung gleichzeitig
ausgeführt wird. Für Dienste vom Typ Type=forking ist der vom Verwalter für
ExecStart= initial gestartete Prozess der Steuerprozess, während der schließlich
mittels Fork gestartete Prozess dann als Hauptprozess der Unit betrachtet wird
(falls er bestimmt werden kann). Dies ist für Dienste-Units von anderen Typen
verschieden, wo der vom Verwalter für ExecStart= mit Fork gestartete Prozess immer
der Hauptprozess selbst ist. Eine Dienste-Unit besteht aus keinem oder einem
Hauptprozess, keinem oder einem Steuerprozess sowie einer beliebigen Anzahl von
zusätzlichen Prozessen. Allerdings verwalten nicht alle Unit-Typen Prozesse dieser
Typen. Für Einhänge-Units sind beispielsweise Steuerprozesse definiert (die die
Aufrufe von /bin/mount und /bin/umount sind), aber es ist kein Hauptprozess
definiert. Falls weggelassen, ist die Vorgabe all.
-s, --signal=
Sucht bei der Verwendung mit kill das Signal aus, das an ausgewählte Prozesse
gesandt wird. Muss eines der gut bekannten Signalkennungen wie SIGTERM, SIGINT oder
SIGSTOP sein. Falls weggelassen, ist die Vorgabe SIGTERM.
Der besondere Wert »help« wird alle bekannten Werte darstellen und das Programm wird
sich sofort beenden; der besondere Wert »list« wird alle bekannten Werte zusammen
mit ihren numerischen Signalnummern darstellen und das Programm wird sich sofort
beenden.
--what=
Wählt aus, welche Art von Unit-bezogenen Ressourcen entfernt werden, wenn der Befehl
clean aufgerufen wird, siehe unten. Akzeptiert entweder configuration, state, cache,
logs oder runtime, um die Art der Ressource auszuwählen. Diese Option kann mehr als
einmal angegeben werden, wodurch alle angegebenen Ressourcentypen entfernt werden.
Akzeptiert auch den besonderen Wert all, als Abkürzung zur Angabe aller fünf
Ressourcentypen. Falls diese Option nicht angegeben ist, ist die Vorgabe die
Kombination von cache und runtime, d.h. den zwei Arten von Ressourcen, die im
Allgemeinen als redundant betrachtet und beim nächsten Aufruf rekonstruiert werden
können.
-f, --force
Setzt bei der Verwendung mit enable alle existierenden, im Konflikt stehenden
Symlinks außer Kraft.
Erstellt bei der Verwendung mit edit alle angegebenen Units, die noch nicht
existieren.
Führt bei der Verwendung mit halt, poweroff, reboot oder kexec die ausgewählten
Aktionen ohne Herunterfahren aller Units aus. Allerdings werden alle Prozesse
zwangsweise beendet und alle Dateisysteme ausgehängt oder neu nur lesbar wieder
eingehängt. Dies ist daher eine drastische, aber relativ sichere Option, um einen
sofortigen Neustart anzufragen. Falls --force zweimal für diese Aktionen angegeben
ist (mit der Ausnahme von kexec), werden sie sofort ausgeführt, ohne alle Prozesse
zu beenden oder Dateisysteme auszuhängen. Warnung: Die zweifache Angabe von --force
mit jeden dieser Aktionen kann zu Datenverlust führen. Beachten Sie, dass bei
zweifacher Angabe von --force die ausgewählte Aktion von systemctl selbst ausgeführt
wird und kein Kontakt zum Systemverwalter aufgenommen wird. Dies bedeutet, dass
dieser Befehl erfolgreich sein sollte, selbst wenn der Systemverwalter abgestürzt
ist.
--message=
Setzt bei der Verwendung mit halt, poweroff oder reboot eine kurze Nachricht, die
den Grund für die Aktion beschreibt. Die Nachricht wird zusammen mit der
Standard-Herunterfahrnachricht protokolliert.
--now
Startet bei der Verwendung mit enable die Units auch. Bei der Verwendung mit disable
oder mask werden die Units auch gestoppt. Die Start- oder Stopp-Aktion wird nur
durchgeführt, wenn die zugehörige Freigabe- oder Ausschaltaktion erfolgreich war.
--root=
Verwendet beim Einsatz mit enable/disable/is-enabled (und verwandten Befehlen) die
angegebenen Wurzelpfade beim Suchen nach Unit-Dateien verwandt. Falls diese Option
vorhanden ist, wird systemctl auf dem Dateisystem direkt arbeiten, statt mit dem
Daemon systemd zu kommunizieren, um die Änderungen auszuführen.
--runtime
Führt bei der Verwendung mit enable, disable, edit (und verwandten Befehlen)
Änderungen nur temporär durch, so dass sie beim nächsten Neustart verloren sind.
Dies hat den Effekt, dass Änderungen nicht in dem Unterverzeichnis von /etc/,
sondern in /run/ durchgeführt werden, mit identischen sofortigen Effekten, da
allerdings die Änderungen bei letzterem beim Neustart verloren gehen, gehen auch die
Änderungen verloren.
Ähnlich erfolgen bei der Verwendung mit set-property die Änderungen nur temporär, so
dass sie beim nächsten Neustart verloren sind.
--preset-mode=
Akzeptiert »full« (die Vorgabe), »enable-only« oder »disable-only«. Steuert bei der
Verwendung mit den Befehlen preset oder preset-all, ob Units entsprechend der
Voreinstellungsregeln ausgeschaltet oder freigegeben oder nur freigegeben oder nur
ausgeschaltet werden sollen.
-n, --lines=
Steuert bei der Verwendung mit status die Anzahl der anzuzeigenden Journal-Zeilen,
gezählt von der neuesten. Akzeptiert als Argument eine positive Ganzzahl oder 0, um
die Journal-Ausgabe zu deaktivieren. Standardmäßig 10.
-o, --output=
Steuert bei der Verwendung mit status die Formatierung der angezeigten
Journal-Einträge. Für die Auswahlmöglichkeiten siehe journalctl(1). Standardmäßig
»short«.
--firmware-setup
Zeigt der Firmware des Systems bei der Verwendung mit dem Befehl reboot an, dass in
die Firmware-Einrichtungsschnittstelle neu gestartet werden soll. Beachten Sie, dass
diese Funktionalität nicht auf allen Systemen verfügbar ist.
--boot-loader-menu=
Zeigt dem System-Bootloader im Zusammenhang mit dem Befehl reboot an, dass der
Bootloader beim nächsten Systemstart das Bootloader-Menü anzeigen soll. Akzeptiert
einen Zeitwert als Parameter, der die Zeitüberschreitung des Menüs angibt. Übergeben
Sie Null, um die Zeitüberschreitung des Menüs zu deaktivieren. Beachten Sie, dass
nicht alle Bootloader diese Funktionalität unterstützten.
--boot-loader-entry=
Zeigt dem System-Bootloader im Zusammenhang mit dem Befehl reboot an, dass der
Bootloader beim nächsten Systemstart in einen bestimmten Bootloader-Eintrag starten
soll. Akzeptiert einen Bootlaoder-Eintragskennzeichner als Argument oder »help«, um
die verfügbaren Einträge anzuzeigen. Beachten Sie, dass nicht alle Bootloader diese
Funktionalität unterstützten.
--reboot-argument=
Dieser Schalter wird mit reboot verwandt. Der Wert ist architektur- und
firmwarespezifisch. Beispielsweise könnte »recovery« zum Auslösen der
Systemwiederherstellung, »fota« könnte zum Auslösen der schnurlosen
Firmware-Aktualisierung verwandt werden.
--plain
Bei der Verwendung mit list-dependencies, list-units oder list-machines wird die
Ausgabe als Liste statt als Baum dargestellt und die Aufzählungskreise werden
weggelassen.
--timestamp=
Ändert das Format der ausgegebenen Zeitstempel. Die folgenden Werte können verwandt
werden:
pretty (dies ist die Vorgabe)
"Tag YYYY-MM-DD HH:MM:SS TZ"
us, µs
"Tag YYYY-MM-DD HH:MM:SS.UUUUUU TZ"
utc
"Tag YYYY-MM-DD HH:MM:SS UTC"
us+utc, µs+utc
"Tag YYYY-MM-DD HH:MM:SS.UUUUUU UTC"
--mkdir
Wird dies mit bind verwandt, dann wird die Zieldatei oder das Zielverzeichnis
erstellt, bevor die Bind-Einhängung angewandt wird. Beachten Sie, dass der Name
dieser Option zwar anzeigt, dass sie nur für Verzeichnisse geeignet ist, sie aber
auch den Zieldateiknoten, über den eingehängt werden soll, falls das einzuhängende
Objekt kein Verzeichnis, sondern eine reguläre Datei, ein Geräteknoten, ein Socket
oder ein FIFO ist, erstellt.
--marked
Nur zusammen mit reload-or-restart erlaubt. Stellt Neustartaufträge für alle Units,
die die Markierung »needs-restart« tragen und Neulade-Aufträge für Units, die die
Markierung »needs-reload« tragen, in die Warteschlange. Wenn eine Unit, die zum
Neuladen markiert ist, kein Neuladen unterstützt, dann wird ein Neustart in die
Warteschlange eingestellt. Diese Eigenschaften können mittels set-property Marks
gesetzt werden.
systemctl wird darauf warten, dass in die Warteschlange eingestellte Aufträge sich
beenden, außer wenn --no-block verwandt wird.
--read-only
Erstellt bei der Verwendung mit bind eine nur lesbare Bind-Einhängung.
-H, --host=
Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen
Benutzernamen und Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden
soll. Dem Rechnernamen darf optional ein Port, auf dem SSH auf Anfragen wartet,
getrennt durch »:« und dann ein Container auf dem angegebenen Host angehängt werden,
womit direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden
wird. Dies verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in
der Ferne zu kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER
aufgezählt werden. Stellen Sie IPv6-Adressen in Klammern.
-M, --machine=
Führt die Aktion in einem lokalen Container aus. Geben Sie den Namen des Containers
an, zu dem verbunden werden soll. Optional kann diesem ein Benutzername, abgetrennt
durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls
die besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird
eine Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
Benutzerbus eines bestimmten Benutzers zu verbinden: »--user
--machine=lennart@.host«. Falls die »@«-Syntax nicht verwandt wird, wird die
Verbindung als Benutzer »root« vorgenommen. Falls die »@«-Syntax verwandt wird, kann
entweder die linke oder die rechte Seite fortgelassen werden (aber nicht beide). In
diesem Fall wird der lokale Benutzername und ».host« angenommen.
--no-pager
Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.
--legend=LOGISCH
Aktiviert oder deaktiviert die Ausgabe der Legende, d.h. der Spaltenüberschriften
und der Fußzeile mit Hinweisen. Standardmäßig wird die Legende ausgegeben, außer
dies wurde mit --quiet oder ähnlichem deaktiviert.
-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.
--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.
EXIT-STATUS
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.
systemctl verwendet die durch LSB definierten Rückgabewerte, wie sie in LSB 3.0.0[1] definiert sind.
Tabelle 3. LSB-Rückgabe-Codes ┌─────┬────────────────────────┬───────────────────────┐ │Wert │ Beschreibung in LSB │ Verwendung in Systemd │ ├─────┼────────────────────────┼───────────────────────┤ │0 │ "Programm läuft oder │ Unit ist aktiv │ │ │ Dienst ist OK" │ │ ├─────┼────────────────────────┼───────────────────────┤ │1 │ "Programm ist tot und │ Unit ist nicht │ │ │ /var/run-PID-Datei │ fehlgeschlagen (von │ │ │ existiert" │ is-failed verwandt) │ ├─────┼────────────────────────┼───────────────────────┤ │2 │ "Programm ist tot und │ nicht verwandt │ │ │ /var/lock-Sperrdatei │ │ │ │ existiert" │ │ ├─────┼────────────────────────┼───────────────────────┤ │3 │ "Programm läuft nicht" │ Unit ist nicht aktiv │ ├─────┼────────────────────────┼───────────────────────┤ │4 │ "Programm- oder │ keine solche Unit │ │ │ Dienstezustand │ │ │ │ unbekannt" │ │ └─────┴────────────────────────┴───────────────────────┘
Die Abbildung der LSB-Dienstezustände auf Systemd-Unit-Zustände ist nicht perfekt. Daher ist es besser, sich nicht auf diese Rückgabewerte zu verlassen, sondern stattdessen nach bestimmten Unit-Zuständen und Unterzuständen zu schauen.
UMGEBUNGSVARIABLEN
$SYSTEMD_EDITOR
Der bei der Bearbeitung von Units zu verwendende Editor: setzt $EDITOR und $VISUAL
außer Kraft. Falls weder $SYSTEMD_EDITOR, $EDITOR noch $VISUAL vorhanden sind oder
falls es auf eine leere Zeichenkette gesetzt ist oder falls seine Ausführung
fehlschlug, wird Systemctl versuchen, gut bekannte Editoren in dieser Reihenfolge
auszuführen: editor(1), nano(1), vim(1), vi(1).
$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer
höheren Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug
oder eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.
$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
ihrer Priorität eingefärbt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal
geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen,
selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.
$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
Zeitstempel vorangestellt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal
oder in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die
Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den
Nachrichten anhängen werden.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und
eine Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.
Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
Fehlersuche in Programmen dennoch praktisch sein.
$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
die Vorgabe) oder null (die Protokollierung deaktivieren).
$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; setzt
$PAGER außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine
Reihe wohlbekannter Textanzeigeprogrammimplementierungen der Reihe nach ausprobiert,
einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Textanzeigeprogrammimplementierung gefunden wird, wird keines aufgerufen. Setzen der
Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur
Übergabe von --no-pager.
$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
Eingabeaufforderung zu erlauben, setzen Sie diese Option zurück.
Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene
Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch
das Textanzeigeprogramm selbst gehandhabt werden.
X
Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs-
und -Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist
standardmäßig gesetzt, damit die Darstellung von Befehlen selbst nach dem
Beenden des Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch
einige Funktionen des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist
das Scrollen in der Ausgabe mit der Maus nicht möglich.
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.
$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
$SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert
nur less(1) einen sicheren Modus.)
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen,
dass keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere«
Modus für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert
werden. Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser
Einstellung aus der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige
Befehle auszuführen. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden
muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen.
Es kann sinnvoll sein, stattdessen den Seitenanzeiger komplett mit --no-pager zu
deaktivieren.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
zu setzen.
$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
Bedingungen trifft, außer Kraft zu setzen.
SIEHE AUCH
systemd(1), journalctl(1), loginctl(1), machinectl(1), systemd.unit(5), systemd.resource-control(5), systemd.special(7), wall(1), systemd.preset(5), systemd.generator(7), glob(7)
ANMERKUNGEN
1. LSB 3.0.0
http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copy‐ right-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.
systemd 250, SYSTEMCTL(1)
<button class="noprint" onclick="topFunction()" id="myBtn" title="Go to top">Top</button>