Systemctl/TMP
TMP
Wichtige Systemd-Befehle
| systemctl | |
| systemctl start sshd.service | |
| systemctl stop sshd.service | |
| systemctl disable sshd.service | |
| systemctl enable sshd.service | |
| systemctl --failed | |
| systemctl isolate graphical.target | |
| systemctl isolate multi-user.target | |
| systemctl daemon-reload |
Listing running services
# systemctl UNIT LOAD ACTIVE SUB JOB DESCRIPTION accounts-daemon.service loaded active running Accounts Service atd.service loaded active running Job spooling tools avahi-daemon.service loaded active running Avahi mDomain Name System/DNS-SD Stack bluetooth.service loaded active running Bluetooth Manager colord-sane.service loaded active running Daemon for monitoring attached scanners and registering them with colord colord.service loaded active running Manage, Install and Generate Color Profiles crond.service loaded active running Command Scheduler cups.service loaded active running CUPS Printing Service dbus.service loaded active running D-Bus System Message Bus ...
Showing runtime status
# systemctl status udisks2.service
udisks2.service - Storage Daemon
Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static)
Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago
Main PID: 615 (udisksd)
CGroup: name=systemd:/system/udisks2.service
└ 615 /usr/lib/udisks2/udisksd --no-debug
Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Runlevel
What would get started?
… if I booted into a specific target?
- If you want systemd to calculate the "initial" transaction it would execute on boot, try something like this:
# systemd --test --system --unit=foobar.target
for a boot target foobar.target. Note that this is mostly a debugging tool that actually does a lot more than just calculate the initial transaction, so don't build scripts based on this.
Change current runlevel
In systemd runlevels are exposed via "target units". You can change them like this:
# systemctl isolate runlevel5.target
- Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:
# systemctl isolate graphical.target
- This will only change the current runlevel, and has no effect on the next boot.
Change default runlevel
- The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:
# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
or
# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target
Current runlevel
Note that there might be more than one target active at the same time. So the question regarding the runlevel might not always make sense. Here's how you would figure out all targets that are currently active:
$ systemctl list-units --type=target
- If you are just interested in a single number, you can use the venerable runlevel command, but again, its output might be misleading.
Enable another getty
Simply instantiate a new getty service for the port of your choice (internally, this places another symlink for instantiating another serial getty in the getty.target.wants/ directory).
# systemctl enable serial-getty@ttyS2.service # systemctl start serial-getty@ttyS2.service
- Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in logind.conf(7). Also see this blog story.
Which service a process belongs to?
You may either use ps for that:
$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc ...
- Or you can even check /proc/$PID/cgroup directly.
- Also see this blog story.
journalctl - display full messages
Even if less is not used?
# journalctl --full
/tmp and tmpfs
- My systemd system always comes up with /tmp as a tiny tmpfs.
- How do I get rid of this?
- That's also a long story, please have a look on:
- API File Systems (http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems)
TMP
BEFEHLE
Unit-Befehle (Untersuchung und Veränderung)
- list-units [MUSTER…]
Listet Units auf, die systemd derzeit im Speicher hat. Dies schließt Units ein, die
entweder direkt oder über eine Abhängigkeit referenziert sind, Units, die durch
Anwendungen programmatisch festgelegt sind und Units, die in der Vergangenheit aktiv
waren und fehlschlugen. Standardmäßig werden nur Units, die aktiv sind, wartende
Aufträge haben oder die fehlschlugen, angezeigt; dies kann mit der Option --all
geändert werden. Falls eines oder mehrere MUSTER angegeben sind, werden nur Units,
die auf diese passen, angezeigt. Die angezeigten Units werden zusätzlich durch
--type= und --state= gefiltert, falls diese Optionen angegeben sind.
Beachten Sie, dass dieser Befehl keine Unit-Vorlagen zeigt, sondern nur Instanzen
von Unit-Vorlagen. Unit-Vorlagen, die nicht instanziiert sind, können nicht
ausgeführt werden und werden daher niemals in der Ausgabe dieses Befehls auftauchen.
Konkret bedeutet dies, dass foo@.service niemals in dieser Liste angezeigt wird –
außer instanziiert, d.h. als foo@bar.service. Verwenden Sie list-unit-files (siehe
unten), um installierte Unit-Vorlagendateien aufzulisten.
Produziert eine Ausgabe ähnlich zu
UNIT LOAD ACTIVE SUB DESCRIPTION
sys-module-fuse.device loaded active plugged /sys/module/fuse
-.mount loaded active mounted Root Mount
boot-efi.mount loaded active mounted /boot/efi
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
● user@1000.service loaded failed failed User Manager for UID 1000
…
systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
123 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Die Kopfzeilen und die letzte Unit des angegebenen Typs werden unterstrichen, falls
das Terminal dies unterstützt. Ein farbiger Punkt wird neben den Diensten, die
maskiert, nicht gefunden oder sonstwie fehlgeschlagen sind, angezeigt.
Die Spalte LOAD zeigt den Ladezustand, einen aus loaded, not-found, bad-setting,
error, masked. Die Spalte ACTIVE zeigt den allgemeinen Unit-Zustand, einen aus
active, reloading, inactive, failed, activating, deactivating. Die Spalte SUB zeigt
den Unit-Typ-spezifischen detaillierten Zustand der Unit, mögliche Werte hängen vom
Unit-Typ ab. Die Liste der möglichen LOAD-, ACTIVE- und SUB-Zustände ist nicht
konstant und neue Systemd-Veröffentlichungen können sowohl Werte hinzufügen als auch
welche entfernen.
systemctl --state=help
Der Befehl kann zur Anzeige der aktuell möglichen Menge von Werten verwandt werden.
Dies ist der Standardbefehl.
- list-sockets [MUSTER…]
Listet aktuell im Speicher befindliche Socket-Units, sortiert nach der Adresse, auf
der sie auf Anfragen warten, auf. Falls eines oder mehrere MUSTER angegeben sind,
werden nur Socket-Units, die darauf passen, angezeigt. Produziert Ausgabe ähnlich zu
LISTEN UNIT ACTIVATES
/dev/initctl systemd-initctl.socket systemd-initctl.service
...
[::]:22 sshd.socket sshd.service
kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
5 sockets listed.
Beachten Sie: Da die Adressen Leerzeichen enthalten können, ist diese Ausgabe nicht
für die programmatische Verarbeitung geeignet.
Siehe auch --show-types, --all und --state=.
- list-timers [MUSTER…]
Listet aktuell im Speicher befindliche Timer-Units, sortiert nach der Zeit, zu der
sie ablaufen, auf. Falls eines oder mehrere MUSTER angegeben sind, werden nur Units,
die darauf passen, angezeigt. Produziert Ausgabe ähnlich zu
NEXT LEFT LAST PASSED UNIT ACTIVATES
n/a n/a Thu 2017-02-23 13:40:29 EST 3 days ago ureadahead-stop.timer ureadahead-stop.service
Sun 2017-02-26 18:55:42 EST 1min 14s left Thu 2017-02-23 13:54:44 EST 3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2017-02-26 20:37:16 EST 1h 42min left Sun 2017-02-26 11:56:36 EST 6h ago apt-daily.timer apt-daily.service
Sun 2017-02-26 20:57:49 EST 2h 3min left Sun 2017-02-26 11:56:36 EST 6h ago snapd.refresh.timer snapd.refresh.service
NEXT zeigt die nächste Zeit, zu der der Timer läuft.
LEFT zeigt die Zeitdauer, bis der Timer das nächste Mal läuft.
LAST zeigt die Zeit, zu der der Timer das letzte Mal lief.
PASSED zeigt, welche Zeit vergangen ist, seitdem der Timer letztmalig lief.
UNIT zeigt den Namen des Timers
ACTIVATES zeigt den Namen des Dienstes, den der Timer beim Laufen aktiviert.
Siehe auch --all und --state=.
- is-active MUSTER…
Prüft, ob eine der angegebenen Units aktiv ist (d.h. läuft). Liefert einen Exit-Code
von 0, falls mindestens eine aktiv ist oder einen von Null verschiedenen Wert
andernfalls. Außer wenn --quiet angegeben ist, wird dies auch den aktuellen Zustand
der Unit auf der Standardausgabe ausgeben.
- is-failed MUSTER…
Prüft, ob eine der angegebenen Units im »fehlgeschlagenen« Zustand ist. Liefert
einen Exit-Code von 0, falls mindestens eine fehlgeschlagen ist oder einen von Null
verschiedenen Wert andernfalls. Außer wenn --quiet angegeben ist, wird dies auch den
aktuellen Zustand der Unit auf der Standardausgabe ausgeben.
- status [MUSTER…|PID…]]
Zeigt knappe Laufzeitstatusinformationen über eine oder mehrere Units, gefolgt von
den neusten Protokolldaten aus dem Journal. Falls keine Units angegeben sind, wird
der Systemstatus angezeigt. In Kombination mit --all wird auch der Status aller
Units angezeigt (in Abhängigkeit von den mit -t angegebenen Einschränkungen). Falls
eine PID übergeben wird, werden die Informationen über die Unit, zu der der Prozess
gehört, angezeigt.
Diese Funktion ist zur Erstellung menschenlesbarer Ausgabe gedacht. Falls Sie nach
Computer-auswertbarer Ausgabe suchen, verwenden Sie stattdessen show. Standardmäßig
zeigt diese Funktion nur die letzten 10 Ausgabezeilen und verkürzte Zeilen, um in
das Terminal-Fenster zu passen. Dies kann mit --lines und --full geändert werden,
siehe oben. Zusätzlich verwenden journalctl --unit=NAME oder journalctl
--user-unit=NAME einen ähnlichen Filter für Nachrichten und könnten praktischer
sein.
Systemd lädt Units implizit nach Notwendigkeit, daher wird die reine Ausführung von
status versuchen, eine Datei zu laden. Der Befehl ist daher nicht nützlich, um zu
bestimmen, ob etwas bereits geladen war oder nicht. Die Units könnten sich auch
schnell entladen, nachdem die Aktion abgeschlossen ist, falls es keinen Grund gibt,
sie danach im Speicher zu halten.
Beispiel 1. Beispielausgabe von systemctl status
$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
Docs: man:bluetoothd(8)
Main PID: 930 (bluetoothd)
Status: "Running"
Tasks: 1
Memory: 648.0K
CPU: 435ms
CGroup: /system.slice/bluetooth.service
└─930 /usr/lib/bluetooth/bluetoothd
Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
Der Punkt (»●«) verwendet auf unterstützten Terminals Farbe, um den Unit-Zustand auf
einen Blick zusammenzufassen. Zusammen mit seiner Farbe ändert sich die Form
entsprechend seines Zustandes: »inaktiv« oder »Wartung« ist ein weißer Kreis (»◈«),
»aktiv« ist ein grüner Punkt (»•«), »Deaktivierend« ist ein weißer Punkt,
»Fehlgeschlagen« oder »Fehler« ist ein rotes Kreuz (»×«) und »Neuladend« ist ein
grüner Kreispfeil im Uhrzeigersinn (»◈«).
Die Zeile »Loaded:« in der Ausgabe wird »loaded« anzeigen, falls die Unit in den
Speicher geladen wurde. Andere mögliche Werte für »Loaded:« sind u.A.: »error«,
falls es ein Problem beim Laden gab, »not-found«, falls für diese Unit keine
Unit-Datei gefunden wurde, »bad-setting«, falls eine essenzielle
Unit-Datei-Einstellung nicht ausgewertet werden konnte und »masked«, falls die
Unit-Datei maskiert wurde. Zusammen mit dem Pfad zu der Unit-Datei wird diese Zeile
auch den Freigabezustand anzeigen. Freigegebene Befehle starten beim Systemstart.
Lesen Sie die vollständige Tabelle der möglichen Freigabezustände — einschließlich
der Definition von »masked« in der Dokumentation für den Befehl »is-enabled«.
Die Zeile »Active:« zeigt den aktiven Zustand. Der Wert ist normalerweise »active«
oder »inactive«. Aktiv kann gestartet, gebunden, eingesteckt usw., abhängig vom
Unit-Typ, sein. Die Unit könnte auch gerade dabei sein, ihre Zustände zu ändern und
einen Zustand »activating« oder »deactivating« melden. Ein besonderer Zustand
»failed« wird erreicht, wenn der Zustand auf irgendeine Art, z. B. durch einen
Absturz, der Beendigung mit einem Fehler-Code oder einer Zeitüberschreitung,
fehlgeschlagen ist. Falls ein Fehlerzustand erreicht wurde, wird der Grund
protokolliert.
- show [MUSTER…|AUFTRAG…]
Zeigt die Eigenschaften einer oder mehrerer Units, von Aufträgen oder dem Verwalter
selbst. Falls kein Argument angegeben ist, werden die Eigenschaften des Verwalters
angezeigt. Falls ein Unit-Name angegeben ist, werden die Eigenschaften der Unit
angezeigt und falls eine Auftragskennung angegeben ist, werden die Eigenschaften des
Auftrags angezeigt. Standardmäßig werden leere Eigenschaften unterdrückt. Verwenden
Sie --all, um diese auch anzuzeigen. Um bestimmte anzuzeigende Eigenschaften
auszuwählen, verwenden Sie --property=. Dieser Befehl ist dazu gedacht, wannimmer
Computer-auswertbare Ausgabe benötigt wird. Verwenden Sie status, falls Sie
formatierte, menschenlesbare Ausgabe wünschen.
Viele durch systemctl show gezeigte Eigenschaften können direkt auf
Konfigurationseigenschaften des System- und Diensteverwalters und seiner
Unit-Dateien abgebildet werden. Beachten Sie, dass die durch den Befehl angezeigten
Eigenschaften im Allgemeinen systemnahe, normalisierte Versionen der ursprünglichen
Konfigurationseinstellungen sind und zusätzlich zur Konfiguration Laufzeitzustand
offenlegen. Eigenschaften für Dienste-Units enthalten beispielsweise die
Kennzeichnung des aktuellen Hauptprozesses des Dienstes als »MainPID« (was
Laufzeitzustand ist) und die Zeiteinstellungen werden immer als Eigenschaften, die
in »…Sec« enden, offengelegt, da Mikrosekunden die vom System- und Diensteverwalter
intern verwandte normierte Zeiteinheit sind.
Für Details zu vielen dieser Eigenschaften lesen Sie die Dokumentation der diesen
Eigenschaften zugrundeliegenden D-Bus-Schnittstellen, siehe
org.freedesktop.systemd1(5).
- cat MUSTER…
Zeigt zugrundeliegende Dateien von einer oder mehr Units. Gibt die »Fragmente« und
»Ergänzungsdateien« (Quelldateien) von Units aus. Jeder Datei wird ein Kommentar
vorangestellt, der den Dateinamen enthält. Beachten Sie, dass dieses die Inhalte der
auf Platte zugrundeliegenden Dateien anzeigt, was sich von dem unterscheiden kann,
was der Systemverwalter von diesen Units denkt, falls die Units seitdem aktualisiert
wurden und nicht der Befehl daemon-reload aufgerufen worden war.
- help MUSTER…|PID…
Zeigt die Handbuchseiten für eine oder mehrere Units, falls verfügbar. Falls eine
PID übergeben wird, wird die Handbuchseite für die Unit, zu der der Prozess gehört,
gezeigt.
- list-dependencies [UNIT…]
Zeigt Units, die von den angegebenen Units benötigt und gewünscht werden. Diese
rekursive Liste folgt den Abhängigkeiten Requires=, Requisite=, ConsistsOf=, Wants=,
BindsTo=. Falls keine Units angegeben sind, wird default.target impliziert.
Standardmäßig werden nur Ziel-Units rekursiv expandiert. Wenn --all übergeben wird,
werden auch alle anderen Units rekursiv expandiert.
Die Optionen --reverse, --after, --before können zur Änderung, welche
Abhängigkeitsarten gezeigt werden, verwandt werden.
Beachten Sie, dass dieser Befehl nur die derzeit durch den Diensteverwalter im
Speicher geladenen Units aufführt. Insbesondere ist dieser Befehl nicht dazu
geeignet, eine vollständige Liste aller inversen Abhängigkeiten einer bestimmten
Unit zu erhalten, da es nicht die von Units erklärten Abhängigkeiten aufführt, die
derzeit nicht geladen sind.
- start MUSTER…
Startet (aktiviert) eine oder mehrere auf der Befehlszeile angegebene Units.
Beachten Sie, dass Unit-Glob-Muster auf die Namen der Units, die momentan im
Arbeitsspeicher sind, expandieren. Units, die nicht aktiv und nicht in einem
fehlgeschlagenen Zustand sind, sind normalerweise nicht im Speicher und es wird kein
Muster auf sie passen. Bei instanziierten Units ist Systemd zusätzlich oft in
Unkenntnis über den Instanzennamen, bis die Instanz gestartet wurde. Daher hat die
Verwendung von Glob-Mustern mit start nur begrenzten Nutzen. Auch werden sekundäre
Alias-Namen von Units nicht berücksichtigt.
Die Option --all kann auch zum Einsatz auf inaktive Units, die von anderen geladenen
Units referenziert werden, verwandt werden. Beachten Sie, dass dies nicht identisch
zum Einsatz auf »alle« möglichen Units ist, da diese Liste nicht korrekt definiert
ist, wie im vorherigen Absatz beschrieben. Dennoch mag systemctl start --all GLOB
nützlich sein, falls alle Units, die auf das Muster passen, durch ein Ziel
hereingezogen werden, welches bekanntermaßen geladen wird.
- stop MUSTER…
Stoppt (deaktiviert) eine oder mehrere auf der Befehlszeile angegebene Units.
Dieser Befehl wird fehlschlagen, falls die Unit nicht existiert oder falls das
Stoppen der Unit verboten ist (siehe RefuseManualStop= in systemd.unit(5)). Er wird
nicht fehlschlagen, falls einer der für das Stoppen der Unit konfigurierten Befehle
((ExecStop= usw.) fehlschlägt, da der Verwalter dennoch die Unit zwangsweise beenden
wird.
- reload MUSTER…
Bittet alle auf der Befehlszeile aufgeführten Units, ihre Konfiguration neu zu
laden. Beachten Sie, dass dies die Dienste-spezifische Konfiguration neu lädt, nicht
die Unit-Konfiguration von Systemd. Falls Sie möchten, dass Systemd die
Konfiguration einer Unit neu lädt, verwenden Sie den Befehl daemon-reload. Mit
anderen Worten: Im Falle von Apache wird dies die httpd.conf neu in den Webserver
laden, nicht die Systemd-Unit-Datei apache.service.
Dieser Befehl sollte nicht mit dem Befehl daemon-reload verwechselt werden.
- restart MUSTER…
Stoppt und startet eine oder mehrere auf der Befehlszeile übergebene Units. Falls
die Units noch nicht laufen, werden sie gestartet.
Beachten Sie, dass das Neustarten einer Unit mit diesem Befehl nicht
notwendigerweise alle Ressourcen der Unit herrausschreibt, bevor sie neu gestartet
wird. Beispielsweise wird die Dienste-bezogene Dateideskriptorspeichereinrichtung
(siehe FileDescriptorStoreMax= in systemd.service(5)) intakt bleiben, solange ein
Auftrag in der Unit wartet und wird nur bereinigt, wenn die Unit komplett gestoppt
wird und keine Aufträge mehr warten. Falls gewünscht ist, dass der
Dateideskriptorspeicher auch rausgeschrieben wird, dann sollte während der
Neustartaktion ein expliziter Befehl systemctl stop gefolgt von systemctl start
eingegeben werden.
- try-restart MUSTER…
Stoppt und startet eine oder mehrere auf der Befehlszeile angegebene Units, falls
die Units laufen. Dies ist wirkungslos, falls die Units nicht laufen.
- reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls sie das unterstützen. Falls nicht, werden
sie stattdessen gestoppt und dann gestartet. Falls die Units noch nicht laufen,
werden sie gestartet.
- try-reload-or-restart MUSTER…
Lädt eine oder mehrere Units neu, falls sie das unterstützen. Falls nicht, werden
sie stattdessen gestoppt und neugestartet. Dies ist wirkungslos, falls die Units
nicht laufen.
- isolate UNIT
Startet die auf der Befehlszeile angegebene Unit und ihre Abhängigkeiten und stoppt
alle anderen, außer sie haben IgnoreOnIsolate=yes (siehe systemd.unit(5)). Falls ein
Unit-Name ohne Erweiterung angegeben wird, wird eine Erweiterung ».target«
angenommen.
Dieser Befehl ist gefährlich, da er sofort Prozesse stoppen wird, die in dem neuen
Ziel nicht freigegeben sind, möglicherweise einschließlich der graphischen Umgebung
oder des Terminals, das Sie gerade benutzen.
Beachten Sie, dass dies nur auf Units erlaubt ist, bei denen AllowIsolate= aktiviert
ist. Siehe systemd.unit(5) für Details.
- kill MUSTER…
Sendet ein Signal an einen oder mehrere Prozesse der Unit. Verwenden Sie
--kill-who=, um den zu tötenden Prozess auszuwählen. Verwenden Sie --signal=, um das
zu sendende Signal auszuwählen.
- clean MUSTER…
Entfernt die Konfiguration, den Zustand, den Zwischenspeicher, die Protokolle oder
die Laufzeitdaten der angegebenen Units. Verwenden Sie --what=, um auszuwählen,
welche Ressourcenarten Sie entfernen möchten.Für Dienste-Units kann dies zur
Entfernung von mit ConfigurationDirectory=, StateDirectory=, CacheDirectory=,
LogsDirectory= und RuntimeDirectory= konfigurierten Verzeichnissen verwandt werden,
siehe systemd.exec(5) für Details. Für Timer-Units kann dies zur Bereinigung der
dauerhaften Zeitstempeldaten verwandt werden, falls Persistent= eingesetzt und
--what=state ausgewählt ist, siehe systemd.timer(5). Dieser Befehl wird nur auf Unit
angewandt, die eine dieser Einstellungen verwenden. Falls --what= nicht angegeben
ist, werden sowohl die Zwischenspeicher- als auch die Laufzeitdaten entfernt (da
diese zwei Datenarten im Allgemeinen redundant und beim nächsten Aufruf der Unit
reproduzierbar sind).
- freeze MUSTER…
Friert eine oder mehrere auf der Befehlszeile angegebene Units mittels des
Cgroup-Freezers ein.
Einfrieren einer Unit führt dazu, dass alle Prozesse in der der Unit entsprechenden
Cgroup suspendiert werden. Suspendiert sein bedeutet, dass die Prozesse der Unit
nicht zur Ausführung auf einer CPU eingeplant werden, bis die Unit aufgetaut wird.
Beachten Sie, dass dieser Befehl nur auf Systemen unterstützt wird, die die
vereinigte Cgroup-Hierarchie verwenden. Die Unit wird automatisch aufgetaut, genau
bevor ein Auftrag gegen die Unit ausgeführt wird, z. B. bevor die Unit gestoppt wird.
- thaw MUSTER…
Taut eine oder mehrere auf der Befehlszeile angegebenen Units auf.
Dies ist die inverse Aktion zum Befehl freeze und nimmt die Ausführung von Prozessen
in der Cgroup der Unit wieder auf.
- set-property UNIT EIGENSCHAFT=WERT…
Setzt die angegebenen Unit-Eigenschaften zur Laufzeit, wo dies unterstützt wird.
Dies erlaubt die Änderung von Konfigurationsparametereigenschaften wie
Ressourcensteuereinstellungen zur Laufzeit. Es können nicht alle Eigenschaften zur
Laufzeit geändert werden, aber viele Ressourcensteuereinstellungen (primär die in
systemd.resource-control(5)). Die Änderungen werden sofort angewandt und auf Platte
für zukünftige Systemstarts gespeichert, außer --runtime wird übergeben, wodurch die
Einstellungen nur bis zum nächsten Systemneustart angewandt werden. Die Syntax der
Eigenschaftszuweisung folgt eng der Syntax der Zuweisungen in Unit-Dateien.
Beispiel: systemctl set-property foobar.service CPUWeight=200
Falls die angegebene Unit-Datei inaktiv zu sein scheint, werden die Änderungen nur
wie früher beschrieben auf Platte gespeichert, daher werden sie erst beim Starten
der Unit zur Geltung kommen.
Beachten Sie, dass dieser Befehl das Ändern mehrerer Eigenschaften auf einmal
erlaubt, was gegenüber der individuellen Einstellung bevorzugt werden sollte.
Beispiel: systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G
IPAccounting=yes
Wie bei Unit-Konfigurationseinstellungen führt die Zuweisung der leeren Einstellung
normalerweise zum Zurücksetzen einer Eigenschaft auf ihre Vorgaben.
Beispiel: systemctl set-property avahi-daemon.service IPAddressDeny=
- bind UNIT PFAD [PFAD]
Hängt eine Datei oder ein Verzeichnis von dem Rechner in den angegebenen
Einhänge-Namensraum der Unit mit bind ein. Das erste Pfadargument ist die Quelldatei
oder das Quellverzeichnis auf dem Rechner, das zweite Pfadargument ist die Zieldatei
oder das Zielverzeichnis in dem Einhänge-Namensraum der Unit. Falls letzteres fehlt,
ist der Zielpfad in dem Einhänge-Namensraum der Unit identisch zum Quellpfad im
Rechner. Wird dies mit dem Schalter --read-only kombiniert, dann wird eine
nur-lesbare Bind-Einhängung erstellt. Wird dies mit dem Schalter --mkdir kombiniert,
dann wird der Zielpfad zuerst erstellt, bevor die Einhängung angewandt wird.
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt wird, die
innerhalb eines Einhängenamensraums ausgeführt werden (z. B. : mit RootImage=,
PrivateMounts= usw.). Dieser Befehl unterstützt die Bind-Einhängung von
Verzeichnissen, regulären Dateien, Geräteknoten, AF_UNIX-Socket-Knoten sowie FIFOs.
Die Bind-Einhängung ist flüchtig und wird sofort zurückgenommen, sobald sich die
Prozesse der aktuellen Unit beenden. Beachten Sie, dass der hier erwähnte
Namensraum, zu dem die Bind-Einhängung hinzugefügt wird, derjenige ist, in dem der
Hauptdiensteprozess ausgeführt wird. Andere Prozesse (die von ExecReload=,
ExecStartPre= usw. ausgeführt werden) laufen in einem dedizierten Namensraum.
- mount-image UNIT ABBILD [PFAD [PARTITIONSNAME
- EINHÄNGEOPTIONEN]]
Hängt eine Abbild von dem Rechner in den angegebene Einhänge-Namensraum der Unit
ein. Das erste Pfadargument ist das Quellabbild auf dem Rechner, das zweite
Pfadargument ist das Zielverzeichnis in dem Einhänge-Namensraum der Unit (d.h.
innerhalb von RootImage=/RootDirectory=). Die folgenden Argumente, falls vorhanden,
werden als Doppelpunkt-getrenntes Tupel von Partitionsnamen und Kommata-getrennten
Listen von Einhängeoptionen für diese Partition interpretiert. Das Format ist
identisch zu der Diensteeinstellung MountImages=. Wird dies mit dem Schalter
--read-only kombiniert, dann wird eine nur-lesbare Einhängung erstellt. Wird dies
mit dem Schalter --mkdir kombiniert, dann wird der Zielpfad zuerst erstellt, bevor
die Einhängung angewandt wird.
Beachten Sie, dass diese Option zur Zeit nur für Units unterstützt wird, die
innerhalb eines Einhängenamensraums ausgeführt werden (d.h. mit RootImage=,
PrivateMounts= usw.). Beachten Sie, dass der hier erwähnte Namensraum, zu dem die
Abbild-Einhängung hinzugefügt wird, derjenige ist, in dem der Hauptdiensteprozess
ausgeführt wird. Beachten Sie, dass der hier erwähnte Namensraum, zu dem die
Bind-Einhängung hinzugefügt wird, der ist, in dem der Hauptdiensteprozess läuft.
Andere Prozesse (die von ExecReload=, ExecStartPre=, usw. ausgeführt werden), laufen
in einem dedizierten Namensraum.
Beispiel:
systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid
systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img
- service-log-level DIENST [STUFE]
Gibt die aktuelle Protokollierstufe, wie sie von DIENST gemeldet wird, aus, falls
das Argument STUFE nicht angegeben ist.
Falls das optionale Argument STUFE bereitgestellt wird, dann wird die aktuelle
Protokollierstufe des Dienstes auf STUFE geändert. Die Protokollierstufe sollte eine
typische Syslog-Protokollierstufe sein, d.h. ein Wert im Bereich 0…7 oder eine der
Zeichenketten emerg, alert, crit, err, warning, notice, info, debug; siehe syslog(3)
für Details.
Der Dienst muss über die geeignete Eigenschaft BusName=Ziel verfügen und auch die
generische Schnittstelle org.freedesktop.LogControl1(5) implementieren. (Systemctl
wird das generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle
org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel verwenden.)
- service-log-target DIENST [ZIEL]
Gibt das aktuelle Protokollierziel, wie es von DIENST gemeldet wird, aus, falls das
Argument ZIEL nicht angegeben ist.
Falls das optionale Argument ZIEL bereitgestellt wird, dann wird das aktuelle
Protokollierziel des Dienstes auf ZIEL geändert. Das Protokollierziel sollte eine
der Zeichenketten console (für das Protokollieren in den Standardfehlerausgabestroms
des Dienstes), kmsg (für das Protokollieren in den Kernelprotokollpufer), journal
(für das Protokollieren nach systemd-journald.service(8) mittels des nativen
Journal-Protokolls), syslog (für das Protokollieren in das klassische Syslog-Socket
/dev/log), null (für keine Protokollierung) oder auto (für eine automatisch
bestimmte Auswahl, typischerweise äquivalent zu console, falls der Dienst interaktiv
aufgerufen wurde und andernfalls journal oder syslog) sein.
Für die meisten Dienste ergeben nur eine kleine Teilmenge der Protokollierziele
Sinn. Insbesondere sollten »normale« Dienste nur console, journal und null
implementieren. Alles andere ist nur für systemnahe Dienste angemessen, die in der
sehr frühen Systemstartphase aktiv sind, bevor korrekte Protokollierung etabliert
ist.
Der Dienst muss über die geeignete Eigenschaft BusName=Ziel verfügen und auch die
generische Schnittstelle org.freedesktop.LogControl1(5) implementieren. (Systemctl
wird das generische D-Bus-Protokoll zum Zugriff auf die Schnittstelle
org.freedesktop.LogControl1.LogLevel für den D-Bus-Namen Ziel verwenden.)
- reset-failed [MUSTER…]
Setzt den Zustand »failed« der angegebenen Unit zurück oder, falls kein Unit-Name
übergeben wird, setzt den Zustand aller Units zurück. Wenn eine Unit auf irgendeine
Art fehlschlägt (d.h. sich der Prozess mit einem von Null verschiedenen Fehler-Code
beendet, sich abnormal beendet oder in eine Zeitüberschreitung läuft), tritt sie
automatisch in den Zustand »failed« und ihr Exit-Code und ihr Status wird zur
Prüfung durch den Administrator aufgezeichnet, bis der Dienst gestoppt/neugestartet
oder mit diesem Befehl zurückgesetzt ist.
Zusätzlich zum Zurücksetzen des Status »failed« einer Unit setzt dies auch
verschiedene andere Unit-bezogene Eigenschaften zurück: der
Startratenbegrenzungszähler aller Unit-Typen wird auf Null zurückgesetzt, wie auch
der Neustartzähler von Dienste-Units. Falls daher die Startbegrenzung (wie mit
StartLimitIntervalSec=/StartLimitBurst= konfiguriert) einer Unit erreicht wird und
die Unit es ablehnt, erneut gestartet zu werden, verwenden Sie diesen Befehl, um sie
wieder startbar zu bekommen.