Versionsgeschichte interaktiv durchsuchen

Version vom 11. Mai 2024, 12:00 Uhr

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.

@@ Zeile 594: / Zeile 594: @@
       die Unit es ablehnt, erneut gestartet zu werden, verwenden Sie diesen Befehl, um sie
       wieder startbar zu bekommen.
+[[Kategorie:Linux/Befehl]]
+[[Kategorie:Systemd]]