Ubuntu Manpage: systemd.special - Spezielle Systemd-Units

BEZEICHNUNG

       systemd.special - Spezielle Systemd-Units

ÜBERSICHT

       basic.target, bluetooth.target, cryptsetup-pre.target, cryptsetup.target,
       veritysetup-pre.target, veritysetup.target, ctrl-alt-del.target, blockdev@.target,
       boot-complete.target, default.target, emergency.target, exit.target, factory-reset.target,
       final.target, first-boot-complete.target, getty.target, getty-pre.target,
       graphical.target, halt.target, hibernate.target, hybrid-sleep.target,
       suspend-then-hibernate.target, initrd.target, initrd-fs.target, initrd-root-device.target,
       initrd-root-fs.target, initrd-usr-fs.target, integritysetup-pre.target,
       integritysetup.target, kbrequest.target, kexec.target, local-fs-pre.target,
       local-fs.target, machines.target multi-user.target, network-online.target,
       network-pre.target, network.target, nss-lookup.target, nss-user-lookup.target,
       paths.target, poweroff.target, printer.target, reboot.target, remote-cryptsetup.target,
       remote-veritysetup.target, remote-fs-pre.target, remote-fs.target, rescue.target,
       rpcbind.target, runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target,
       shutdown.target, sigpwr.target, sleep.target, slices.target, smartcard.target,
       sockets.target, sound.target, suspend.target, swap.target, sysinit.target,
       system-update.target, system-update-pre.target, time-set.target, time-sync.target,
       timers.target, umount.target, usb-gadget.target, -.slice, system.slice, user.slice,
       machine.slice, -.mount, dbus.service, dbus.socket, display-manager.service, init.scope,
       syslog.socket, system-update-cleanup.service

BESCHREIBUNG

       Einige wenige Units werden durch Systemd besonders behandelt. Viele von ihnen haben
       besondere interne Semantiken und können nicht umbenannt werden, während andere einfach
       über eine Standardbedeutung verfügen und auf allen Systemen vorhanden sein sollten.

UNITS, DIE VOM SYSTEMDIENSTEVERWALTER VERWALTET WERDEN

Spezielle System-Units:
-.mount
Der Wurzeleinhängepunkt, d.h. die Einhänge-Unit für den Pfad /. Diese Unit ist
bedingungslos während der gesamten Laufzeit des Systems aktiv, da dies der
Einhängepunkt ist, von dem der grundlegende Anwendungsbereich aus läuft.

basic.target
Eine besondere Ziel-Unit, die den grundlegenden Systemstart abdeckt.

Systemd fügt automatisch Abhängigkeiten vom Typ After= für diese Ziel-Unit an alle
Dienste (außer denen mit DefaultDependencies=no) hinzu.

Normalerweise sollte diese alle lokalen Einhängepunkte plus /var/, /tmp/ und
/var/tmp/, Auslagerungsgeräte, Sockets, Timer, Pfad-Units und andere notwendige
grundlegende Initialisierungen für die Universal-Daemons hineinziehen. Die erwähnten
Einhängepunkte sind Spezialfälle, damit sie auf Rechnern in der Ferne liegen können.

Dieses Ziel zieht normalerweise keine Nicht-Ziel-Units direkt hinein, sondern erledigt
dies über andere Ziele der frühen Systemstartphase indirekt. Es ist stattdessen als
Synchronisationspunkt für späte Systemstartdienste gedacht. Schauen Sie in bootup(7)
für Details über die beteiligten Ziele.

boot-complete.target
Dieses Ziel ist als generischer Synchronisationspunkt für Dienste gedacht, die
abhängig davon, ob der Systemstartprozess erfolgreich abgeschlossen wurde, bestimmen
oder handeln sollen. Sortieren Sie Units, die für den erfolgreichen Abschluss des
Systemstartprozesses benötigt werden, vor diese Unit und fügen Sie eine Abhängigkeit
Requires= von der Ziel-Unit auf sie hinzu. Sortieren Sie Units, die nur ausgeführt
werden sollen, wenn der Systemstartprozess als erfolgreich abgeschlossen betrachtet
wird, nach dieser Ziel-Unit und ziehen Sie in ihr das Ziel herein, auch mit Requires=.
Beachten Sie, dass diese Ziel-Unit standardmäßig kein Teil der anfänglichen
Systemstarttransaktion ist und sie nur hereingezogen werden soll, falls das von Units
benötigt wird, die nur nach einem erfolgreichen Start ausgeführt werden möchten.

Siehe systemd-boot-check-no-failures.service(8) für einen Dienst, der eine generische
Systemgesundheitsprüfung implementiert und sich selbst nach boot-complete.target
einsortiert.

Siehe systemd-bless-boot.service(8) für einen Dienst, der Systemstartinformationen an
das Systemstartprogramm weiterleitet und sich selbst nach boot-complete.target
einsortiert.

ctrl-alt-del.target
Systemd startet dieses Ziel, wann immer Strg+Alt+Entf auf der Konsole gedrückt wird.
Normalerweise sollte dies auf reboot.target gesymlinkt sein.

cryptsetup.target
Ein Ziel, das die Einrichtungsdienste für alle verschlüsselten Blockgeräte
hereinzieht.

veritysetup.target
Ein Ziel, das die Einrichtungsdienste für alle Verity-integritätsgeschützten
Blockgeräte hereinzieht.

dbus.service
Eine besondere Unit für den D-Bus-Bus-Daemon.s Sobald dieser Dienst voll gestartet
ist, wird sich Systemd mit ihm verbinden und seinen Dienst registrieren.

dbus.socket
Eine besondere Unit für das D-Bus-System-Bus-Socket. Alle Units mit Type=dbus erlangen
automatisch eine Abhängigkeit auf diese Unit.

default.target
Die Vorgabe-Unit, die Systemd beim Systemstart startet. Normalerweise sollte dies auf
multi-user.target oder graphical.target gealiast (gesymlinkt) werden. Siehe bootup(7)
für weitergehende Besprechung.

Die Vorgabe-Unit, die Systemd beim Systemstart startet, kann mit der
Kernelbefehlszeilenoption systemd.unit= oder bequemer mit den Kurznamen wie single,
rescue, 1, 3, 5, … außer Kraft gesetzt werden, siehe systemd(1).

display-manager.service
Der Display-Manager-Dienst. Normalerweise sollte dieser auf gdm.service oder einen
ähnlichen Display-Manager-Dienst gealiast (symlinkt) werden.

emergency.target
Eine besondere Ziel-Unit, die eine Notfall-Shell auf der Hauptkonsole startet. Diese
Ziel zieht keine anderen Dienste oder Einhängungen herein. Es ist die minimalste
Version eines Systemstarts, um eine interaktive Shell zu erlangen; die einzigen
laufenden Prozesse sind normalerweise nur der Systemverwalter (PID 1) und der
Shell-Prozess. Diese Unit kann durch Verwendung von emergency auf der
Kernel-Befehlszeile verwandt werden; sie wird auch verwandt, wenn eine
Dateisystemprüfung auf einem benötigten Dateisystem fehlschlägt und der Systemstart
nicht fortfahren kann. Vergleichen Sie sie mit rescue.target, das einem ähnlichen
Zweck dient, aber auch die grundlegendsten Dienste startet und alle Dateisysteme
einhängt.

Auf viele Arten und Weisen ist der Systemstart in emergency.target ähnlich zu dem
Effekt des Systemstarts mit »init=/bin/sh« auf der Kernelbefehlszeile, außer dass der
Notfallmodus Ihnen ein komplettes System und einen Diensteverwalter bereitstellt und
es Ihnen erlaubt, individuelle Units zu starten, um den Systemstartvorgang
schrittweise fortzusetzen.

Beachten Sie, dass abhängig davon, wie emergency.target erreicht wird, das
Wurzeldateisystem schreibgeschützt oder schreibbar eingehängt sein könnte (es wird
nicht speziell für dieses Ziel neu eingehängt). Beispielsweise kann das System mit
schreibgeschützter Wurzel gestartet werden, wenn ro auf der Kernelbefehlszeile
angegeben wird und so für emergency.target verbleiben, oder das System könnte zu
emergency.target überleiten, nachdem das System teilweise gestartet wurde und die
Platten bereits schreibbar neu eingehängt wurden.

exit.target
Eine besondere Dienste-Unit zum Herunterfahren des Systems oder
Benutzerdiensteverwalters. Es ist äquivalent zum poweroff.target auf nicht
Container-Systemen und funktioniert auch in Containern.

Systemd wird diese Unit starten, wenn es das Signal SIGTERM oder SIGINT empfängt, wenn
es als Benutzerdienste-Daemon läuft.

Normalerweise zieht dies (indirekt) shutdown.target mit herein, was wiederum in
Konflikt zu allen Units stehen sollte, die für das Herunterfahren eingeplant werden
wollen, wenn der Systemverwalter anfängt, sich zu beenden.

factory-reset.target
Ein besonderes Ziel, um das Rücksetzen in den Werkszustand auszulösen.

final.target
Eine besondere Ziel-Unit, die während der Herunterfahrlogik verwandt wird und dazu
eingesetzt werden kann, späte Dienste hereinzuziehen, nachdem alle normalen Dienste
sich bereits beendet und alle Einhängungen ausgehängt haben.

getty.target
Eine besondere Ziel-Unit, die statisch konfigurierte lokale TTY-Getty-Instanzen
hereinzieht.

graphical.target
Eine besondere Ziel-Unit zum Einrichten eines graphischen Anmeldebildschirms. Dies
zieht multi-user.target herein.

Units, die für graphische Anmeldebildschirme benötigt werden, sollten während der
Installation Abhängigkeiten Wants= für ihre Unit auf diese Unit (oder
multi-user.target) hinzufügen. Am besten wird dies über WantedBy=graphical.target im
Abschnitt »[Install]« in der Unit konfiguriert.

hibernate.target
Eine besondere Ziel-Unit zum Schlafenlegen des Systems. Dies zieht sleep.target
herein.

hybrid-sleep.target
Eine besondere Ziel-Unit zum Schlafenlegen und gleichzeitigen Suspendieren des
Systems. Dies zieht sleep.target herein.

suspend-then-hibernate.target
Eine besondere Ziel-Unit zur Suspendierung des System für eine bestimmte Zeitperiode,
zum Aufwachen und zum Schlafenlegen des Systems. Dies zieht sleep.target herein.

halt.target
Eine besondere Ziel-Unit zum Herunterfahren und Anhalten des Systems. Beachten Sie,
dass dieses Ziel sich von poweroff.target darin unterscheidet, dass es im Allgemeinen
nur das System anhält, statt es auszuschalten.

Anwendungen, die das System anhalten wollen, sollten diese Unit nicht direkt starten,
sondern stattdessen systemctl halt (möglicherweise mit der Option --no-block)
ausführen oder die D-Bus-Methode org.freedesktop.systemd1.Manager.Halt von systemd(1)
direkt aufrufen.

init.scope
In dieser Bereichs-Unit befindet sich der System- und Diensteverwalter (PID 1) selbst.
Sie ist aktiv, solange das System läuft.

initrd.target
Dies ist das Standardziel in der Initramfs, ähnlich zu default.target im Hauptsystem.
Es wird zum Einhängen der echten Wurzel und dem Übergang dahin verwandt. Siehe
bootup(7) für eine Besprechung.

initrd-fs.target
systemd-fstab-generator(3) fügt automatisch Abhängigkeiten vom Typ Before= von
sysroot-usr.mount und allen in /etc/fstab gefundenen Einhängepunkten, die
Einhängeoptionen x-initrd.mount gesetzt und nicht die noauto gesetzt haben, hinzu. Er
wird auch indirekt nach sysroot.mount einsortiert. Daher ist die /sysroot/-Hierarchie
komplett eingerichtet, wenn dieses Ziel erreicht ist, vorbereitet für die Überleitung
zum Betriebssystem des Rechners.

initrd-root-device.target
Eine besondere Initrd-Ziel-Unit, die erreicht wird, wenn das Wurzeldateisystemgerät
verfügbar, aber bevor es eingehängt ist. systemd-fstab-generator(3) und
systemd-gpt-auto-generator(3) richten automatisch die geeigneten Abhängigkeiten ein,
damit dies erreicht wird.

initrd-root-fs.target
systemd-fstab-generator(3) fügt automatisch Abhängigkeiten vom Typ Before= zu der Unit
sysroot.mount, die aus Einstellung root= (oder äquivalent) der Kernelbefehlszeile
erstellt wird, hinzu.

initrd-usr-fs.target
systemd-fstab-generator(3) fügt automatisch Abhängigkeiten vom Typ Before= zu der Unit
sysusr-usr.mount hinzu, die von dem Schalter usr= der Kernelbefehlszeile erstellt
wird. Ziele können sich nach dieser Ziel-Unit einsortieren, um einmal ausgeführt zu
werden, sobald die /sysusr/-Hierarchie verfügbar wird, auf Systemen, die anfänglich
ohne ein Wurzeldateisystem, aber mit einem initialisierten /usr/ daherkommen und auf
Letzteres zugreifen müssen, bevor schließlich das Wurzeldateisystem eingerichtet wird,
wohin letztendlich umgeschaltet wird. Auf Systemen, auf denen usr= nicht verwandt
wird, wird dieses Ziel nach sysroot.mount einsortiert und ist daher größtenteils
äquivalent zu initrd-root-fs.target. Auf jedem System wird das /usr/ zugrundeliegende
Dateisystem eingehängt, sobald dieses Ziel erreicht wird, allerdings möglicherweise an
zwei verschiedenen Orten, entweder unterhalb von /sysusr/ oder den
/sysroot/-Hierarchien.

kbrequest.target
Systemd startet dieses Ziel, wann immer Alt+PfeilHoch auf der Konsole gedrückt wird.
Beachten Sie, dass dies jeder Benutzer mit physischem Zugang zu der Maschine ohne
Authentifizierung machen kann, daher sollte dies vorsichtig genutzt werden.

kexec.target
Eine besondere Ziel-Unit für das Herunterfahren und Neustarten des Systems mittels
kexec.

Anwendungen, die das System neu starten möchten, sollten diese Unit nicht direkt
starten, sondern stattdessen systemctl kexec (möglicherweise mit der Option
--no-block) ausführen oder die D-Bus-Methode org.freedesktop.systemd1.Manager.KExec
von systemd(1) direkt aufrufen.

local-fs.target
systemd-fstab-generator(3) fügt automatisch Ziele vom Typ Before= zu allen
Einhänge-Units, die sich auf lokale Einhängepunkte beziehen, für diese Ziel-Unit
hinzu. Zusätzlich fügt es Abhängigkeiten vom Typ Wants= zu dieser Ziel-Unit für solche
Einhängepunkte von Einhängungen, die in /etc/fstab mit der gesetzten Option auto
aufgeführt sind, hinzu.

machines.target
Eine Standard-Ziel-Unit zum Starten aller Container und anderer virtueller Maschinen.
Siehe systemd-nspawn@.service für ein Beispiel.

multi-user.target
Eine besondere Ziel-Unit zum Einrichten eines Mehrbenutzersystems (nicht graphisch).
Diese wird von graphical.target hereingezogen.

Units, die für Mehrbenutzersysteme benötigt werden, müssen Wants=-Abhängigkeiten für
ihre Unit auf diese Unit während der Installation hinzufügen. Dies wird am besten
mittels WantedBy=multi-user.target in dem Abschnitt »[Install]« der Unit konfiguriert.

network-online.target
Units, die strikt ein konfiguriertes Netz benötigen, sollten (mittels einer
Wants=-artigen Abhängigkeit) network-online.target hereinziehen und sich danach
anordnen. Diese Ziel-Unit ist dazu gedacht, einen Dienst hereinzuziehen, der die
weitere Ausführung verzögert, bis das Netzwerk hinreichend eingerichtet ist. Was genau
dies benötigt, wird der Implementierung des Netzverwaltungsdienstes überlassen.

Beachten Sie den Unterschied zwischen dieser Unit und network.target. Diese Unit ist
eine aktive Unit (d.h. sie wird vom Konsumenten statt vom Anbieter dieser
Funktionalität hereingezogen) und zieht einen Dienst herein, der möglicherweise
substanzielle Verzögerungen für die weitere Ausführung hinzufügt. Im Gegensatz dazu
ist network.target eine passive Unit (d.h. sie wird vom Anbieter der Funktionalität
statt vom Konsumenten hereingezogen), die normalerweise die Ausführung nicht viel
verzögert. Normalerweise ist network.target Teil des Systemstarts der meisten Systeme,
während network-online.target dies nicht ist, außer wenn mindestens eine Unit es
verlangt. Siehe auch Dienste ausführen, nachdem das Netz oben ist[1] für weitere
Informationen.

Alle Einhänge-Units für ferne Netzwerkdateisysteme ziehen diese Unit automatisch
herein und sortieren sich danach ein. Beachten Sie, dass Netzwerk-Daemons, die einfach
für andere Rechner Funktionalitäten anbieten (im Gegensatz zur
Verbrauch-Funktionalität anderer Rechner), im Allgemeinen diese Unit nicht
hereinziehen müssen.

Systemd fügt automatisch Abhängigkeiten vom Typ Wants= und After= für diese Ziel-Unit
zu allen SysV-Init-Skripte-Dienste-Units hinzu, bei denen eine LSB-Kopfzeile auf die
Einrichtung »$network« referenziert.

Beachten Sie, dass diese Unit nur während der ursprünglichen Systemstartlogik sinnvoll
ist. Nachdem das System komplett hochgefahren ist, wird es den Online-Status des
Systems nicht mehr nachverfolgen. Daher kann es auch nicht als
Netzwerküberwachungskonzept verwandt werden, es ist ein reines, einmaliges
Systemstartkonzept.

paths.target
Eine besondere Ziel-Unit, die alle Pfad-Units einrichtet (siehe systemd.path(5) für
Details), die nach dem Systemstart aktiv sein sollen.

Es wird empfohlen, dass durch Anwendungen installierte Pfad-Units von
Wants=-Abhängigkeiten auf diese Unit hereingezogen werden. Dies wird am besten mittels
WantedBy=paths.target in dem Abschnitt »[Install]« der Pfad-Unit konfiguriert.

poweroff.target
Eine besondere Ziel-Unit zum Herunterfahren und Ausschalten des Systems.

Anwendungen, die das System herunterfahren möchten, sollten diese Unit nicht direkt
starten, sondern stattdessen systemctl poweroff (möglicherweise mit der Option
--no-block) ausführen oder die D-Bus-Methode org.freedesktop.login1.Manager.PowerOff
von systemd-logind(8) direkt aufrufen.

runlevel0.target ist ein Alias zur Kompatibilität mit SysV für diese Ziel-Unit.

reboot.target
Eine besondere Ziel-Unit zum Herunterfahren und Neustarten des Systems.

Anwendungen, die das System neustarten möchten, sollten diese Unit nicht direkt
starten, sondern stattdessen systemctl reboot (möglicherweise mit der Option
--no-block) ausführen oder die D-Bus-Methode org.freedesktop.login1.Manager.Reboot von
systemd-logind(8) direkt aufrufen.

runlevel6.target ist ein Alias zur Kompatibilität mit SysV für diese Ziel-Unit.

remote-cryptsetup.target
Ähnlich zu cryptsetup.target, aber für verschlüsselte Geräte, auf die über das Netz
zugegriffen wird. Sie wird für crypttab(8)-Einträge, die mit _netdev markiert sind,
verwandt.

remote-veritysetup.target
Ähnlich zu veritysetup.target, aber für Verity-integritätsgeschützte Geräte, auf die
über das Netz zugegriffen wird. Sie wird für veritytab(8)-Einträge, die mit _netdev
markiert sind, verwandt.

remote-fs.target
Ähnlich zu local-fs.target, aber für ferne Einhängepunkte.

Systemd fügt automatisch Abhängigkeiten vom Typ After= für diese Ziel-Unit zu allen
SysV-Init-Skripte-Dienste-Units hinzu, bei denen eine LSB-Kopfzeile auf die
Einrichtung »remote_fs« referenziert.

rescue.target
Eine besondere Ziel-Unit, die das Basissystem (einschließlich Systemeinhängungen)
hereinzieht und eine Notfall-Shell startet. Isolieren Sie zu diesem Ziel, um das
System im Einzelbenutzermodus mit allen Dateisystemen eingehängt, aber ohne laufende
Dienste (außer den grundlegendsten) zu administrieren). Vergleichen Sie dies mit
emergency.target, das deutlich reduzierter ist und keine Dateisysteme oder
grundlegendste Dienste bereitstellt. Im Vergleich zu multi-user.target könnte dieses
Ziel als single-user.target betrachtet werden.

runlevel1.target ist ein Alias zur Kompatibilität mit SysV für diese Ziel-Unit.

Verwenden Sie die Kernelbefehlszeilenoption »systemd.unit=rescue.target«, um in diesen
Modus zu starten. Ein kurzer Alias für diese Kernelbefehlszeilenoption ist »1«, zur
Kompatibilität mit SysV.

runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target
Dies sind die Ziele, die aufgerufen werden, wenn der SysV-Kompatibilitätscode nach den
Runleveln 2, 3, 4 bzw. 5 fragt. Es ist eine gute Idee, diese zu einem Alias von (d.h.
einen Symlink auf) graphical.target (für Runlevel 5) oder multi-user.target (die
anderen) zu machen.

shutdown.target
Eine besondere Ziel-Unit, die die Dienste beim Herunterfahren des Systems beendet.

Dienste, die beim Herunterfahren des Systems beendet werden sollen, sollten eine
Abhängigkeit Conflicts= und Before= auf diese Unit zu ihrer Dienste-Unit hinzufügen,
was implizit passiert, wenn DefaultDependencies=yes gesetzt ist (die Vorgabe).

sigpwr.target
Ein besonderes Ziel, das gestartet wird, wenn Systemd das SIGPWR-Prozesssignal erhält,
was normalerweise vom Kernel oder UPS-Daemon gesandt wird, wenn die Stromversorgung
zusammenbricht.

sleep.target
Eine besondere Ziel-Unit, die durch suspend.target, hibernate.target und
hybrid-sleep.target hereingezogen wird und dazu verwandt werden kann, Units in die
Einschlafzustandslogik einzuhängen.

slices.target
Eine besondere Ziel-Unit, die alle Scheiben-Units (siehe systemd.slice(5) für Details)
einrichtet, die nach dem Systemstart immer aktiv sein sollen. Standardmäßig wird die
generische Scheiben-Unit system.slice sowie die Wurzelscheiben-Unit -.slice
hereingezogen und vor dieser Unit angeordnet (siehe unten).

Normalerweise ist es nicht notwendig, Scheiben-Units zu slices.target hinzuzufügen.
Stattdessen wird die festgelegte Scheibe automatisch gestartet, wenn eine Unit, die
Slice= verwendet, gestartet wird. Hinzufügen von WantedBy=slices.target-Zeilen zu dem
Abschnitt »[Install]« sollte nur für Units erfolgen, die immer aktiv sein müssen. In
diesem Fall müssen Sie darauf achten, dass keine Schleife zu der automatischen
Abhängigkeit der »Eltern«-Scheibe erzeugt wird.

sockets.target
Eine besondere Ziel-Unit, die alle Socket-Units einrichtet (siehe systemd.socket(5)
für Details), die nach dem Systemstart aktiv sein sollen.

Dienste, die Socket-aktivierbar sein sollen, sollen eine Abhängigkeit Wants= von
dieser Unit für ihre Socket-Unit während der Installation hinzufügen. Dies wird am
besten mittels WantedBy=sockets.target im Abschnitt »[Install]« der Socket-Unit
konfiguriert.

suspend.target
Eine besondere Ziel-Unit für die Suspendierung des Systems. Dies zieht sleep.target
herein.

swap.target
Ähnlich zu local-fs.target, aber für Auslagerungspartitionen und -dateien.

sysinit.target
Systemd fügt automatisch Abhängigkeiten vom Typ Requires= und After= für diese
Ziel-Unit zu allen Diensten (außer für solche mit DefaultDependencies=no) hinzu.

Dieses Ziel zieht alle Dienste herein, die für die Systeminitialisierung benötigt
werden. Systemdienste, die durch dieses Ziel hereingezogen werden, sollten
DefaultDependencies=no deklarieren und alle ihre Abhängigkeiten manuell festlegen,
einschließlich Zugriff auf alles, was mehr als ein rein lesbares Wurzeldateisystem
ist. Für Details zu den Abhängigkeiten dieses Zieles lesen Sie bitte bootup(7).

syslog.socket
Die Socket-Unit, an der die Syslog-Implementierung auf Anfragen warten soll. Alle
Protokollmeldungen aus dem Anwendungsbereich werden auf diesem Socket zur Verfügung
gestellt. Für weitere Informationen über die Syslog-Integration schlagen Sie bitte im
Dokument Syslog-Schnittstelle[2] nach.

system-update.target, system-update-pre.target, system-update-cleanup.service
Eine besondere Ziel-Unit, die für Offline-Systemaktualisierungen verwandt wird.
systemd-system-update-generator(8) wird den Systemstartprozess auf dieses Ziel
umlenken, falls /system-update existiert. Für weitere Informationen siehe
systemd.offline-updates(7).

Aktualisierungen sollten stattfinden, bevor das Ziel system-update.target erreicht
wird und die Dienste, die es implementieren, sollten einen Neustart der Maschine
auslösen. Die Haupt-Units, die die Aktualisierung ausführen, sollten sich nach
system-update-pre.target einsortieren, es aber nicht hereinziehen. Dienste, die nur
während der Systemaktualisierung laufen möchten, aber bevor die eigentliche
Systemaktualisierung ausgeführt wird, sollten sich vor dieser Unit einordnen und sie
hereinziehen. Als Sicherheitsmaßnahme wird system-update-cleanup.service diesen
Symlink entfernen und die Maschine neustarten, falls vorheriges nicht passiert und
/system-update noch existiert, nachdem system-update.target erreicht wurde.

timers.target
Eine besondere Ziel-Unit, die alle Timer-Units einrichtet (siehe systemd.timer(5) für
Details), die nach dem Systemstart aktiv sein sollen.

Es wird empfohlen, dass durch Anwendungen installierte Timer-Units durch
Abhängigkeiten Wants= von dieser Unit hereingezogen werden. Dies wird am besten
mittels WantedBy=timers.target in dem Abschnitt »[Install]« der Timer-Unit
konfiguriert.

umount.target
Eine besondere Ziel-Unit, die alle Einhänge- und Selbsteinhängepunkte beim
Herunterfahren des Systems aushängt.

Einhängungen, die beim Herunterfahren des Systems ausgehängt werden sollen, müssen
Konfliktabhängigkeiten zu dieser Unit für ihre Einhänge-Unit hinzufügen. Dies erfolgt
implizit, wenn DefaultDependencies=yes gesetzt ist (die Vorgabe).

Spezielle System-Units für Geräte
Einige Ziel-Units werden automatisch hereingezogen, wenn Geräte eines bestimmten Typs im
System auftauchen. Diese können dazu verwandt werden, automatisch verschiedene Dienste,
basierend auf dem spezifischen Typ der verfügbaren Hardware, zu aktivieren.

bluetooth.target
Dieses Ziel wird automatisch gestartet, sobald ein Bluetooth-Controller eingesteckt
oder beim Systemstart verfügbar wird.

Dies kann dazu verwandt werden, dynamisch Bluetooth-Verwaltungs-Daemons
hereinzuziehen, wenn Bluetooth-Hardware gefunden wird.

printer.target
Dieses Ziel wird automatisch gestartet, sobald ein Drucker eingesteckt oder beim
Systemstart verfügbar wird.

Dies kann dazu verwandt werden, dynamisch Druckerverwaltungs-Daemons hereinzuziehen,
wenn Drucker-Hardware gefunden wird.

smartcard.target
Dieses Ziel wird automatisch gestartet, sobald ein Smartcard-Controller eingesteckt
oder beim Systemstart verfügbar wird.

Dies kann zum dynamischen Hereinziehen von Smartcard-Verwaltungs-Daemons verwandt
werden, wenn Smartcard-Hardware gefunden wird.

sound.target
Dieses Ziel wird automatisch gestartet, sobald eine Soundkarte eingesteckt wird oder
beim Systemstart verfügbar wird.

Dies kann zum dynamischen Hereinziehen von Audio-Verwaltungs-Daemons verwandt werden,
wenn Audio-Hardware gefunden wird.

usb-gadget.target
Dieses Ziel wird automatisch gestartet, sobald ein USB-Geräte-Controller beim
Systemstart verfügbar wird.

Dies kann zum dynamischen Hereinziehen von USB-Geräten verwandt werden, wenn
UDC-Hardware gefunden wird.

Spezielle passive System-Units
Es sind eine Reihe von besonderen Systemzielen definiert, die dazu verwandt werden können,
um das Hochfahren optionaler Dienste zu sortieren. Diese Ziele sind im Allgemeinen nicht
Teil der Systemstarttransaktion, außer sie werden explizit durch einen der
implementierenden Dienste hereingezogen. Beachten Sie insbesondere, dass diese passiven
Ziel-Units im Allgemeinen nicht durch die Benutzer eines Dienstes hereingezogen werden,
sondern durch den Anbieter des Dienstes. Dies bedeutet: Ein Benutzer-Dienst sollte sich
(passend) nach diesen Zielen einsortieren, sie aber nicht hereinziehen Ein anbietender
Dienst sollte sich (geeignet) vor diesen Zielen einsortieren und sie (mittels einer
Wants=-artigen Abhängigkeit) hereinziehen.

Beachten Sie, dass diese passiven Units nicht manuell gestartet werden können, d.h.
»systemctl start time-sync.target« wird mit einem Fehler fehlschlagen. Sie können nur über
Abhängigkeiten hereingezogen werden. Dies wird durchgesetzt, da sie nur für Ordnungszwecke
existieren, und daher keinen Sinn als einzige Unit innerhalb einer Transaktion ergeben.

blockdev@.target
Diese Vorlagen-Unit wird zur Sortierung von Einhänge-Units und anderen Nutzern von
Blockgeräten hinter andere Dienste, die diese Blockgeräte künstlich erstellen,
verwandt. Insbesondere wird dies zur Verwendung mit Speicherdiensten (wie
systemd-cryptsetup@.service(5)/systemd-veritysetup@.service(5)), die virtuelle
Blockgeräte reservieren und verwalten, benutzt. Speicherdienste werden vor einer
Instanz von blockdev@.target einsortiert und die Nutzer-Units danach. Die Sortierung
ist insbesondere während des Herunterfahrens des Systems relevant, da sie
sicherstellt, dass zuerst die Einhängung deaktiviert wird und dann erst der Dienst,
der der Einhänung hinterlegt ist. Die Instanz blockdev@.target sollte mittels einer
Wants=-Abhängigkeit von dem Speicher-Daemon hereingezogen und daher im Allgemeinen
nicht Teil irgendeiner Transaktion sein, falls kein Speicher-Daemon verwandt wird. Der
Instanzenname für Instanzen dieser Vorlage-Unit muss ein korrekt maskierter
Blockgeräteknotenpfad sein, z.B. blockdev@dev-mapper-foobar.target für das
Speichergerät /dev/mapper/foobar.

cryptsetup-pre.target
Diese passive Ziel-Unit kann durch Dienste, die ausgeführt werden wollen, bevor
irgendein verschlüsseltes Blockgerät eingerichtet wurde, hereingezogen werden. Alle
verschlüsselten Blockgeräte werden eingerichtet, nachdem dieses Ziel erreicht wurde.
Da die Herunterfahrreihenfolge zwischen Units implizit die Umkehrung der
Hochfahrreihenfolge ist, ist dieses Ziel insbesondere nützlich, um sicherzustellen,
dass ein Dienst nur heruntergefahren wird, nachdem alle verschlüsselten Blockgeräte
vollständig gestoppt wurden.

veritysetup-pre.target
Diese passive Ziel-Unit kann durch Dienste, die ausgeführt werden wollen, bevor
irgendein Verity-integritätsgeschütztes Blockgerät eingerichtet wurde, hereingezogen
werden. Alle Verity-integritätsgeschützten Blockgeräte werden eingerichtet, nachdem
dieses Ziel erreicht wurde. Da die Herunterfahrreihenfolge zwischen Units implizit die
Umkehrung der Hochfahrreihenfolge ist, ist dieses Ziel insbesondere nützlich, um
sicherzustellen, dass ein Dienst nur heruntergefahren wird, nachdem alle
Verity-Integritätsgeschützten Blockgeräte vollständig gestoppt wurden.

first-boot-complete.target
Dieses passive Ziel ist als Synchronisationspunkt für Units, die einmal während des
ersten Systemstarts ausgeführt werden müssen, gedacht. Erst nachdem alle Units, die
vor dieses Ziel einsortiert wurden, sich beendet haben, wird machine-id(5) auf die
Platte übertragen, wodurch der erste Systemstart als abgeschlossen markiert wird.
Falls der Systemstart irgendwann davor abgebrochen wird, dann wird der nächste
Systemstart alle Units mit ConditionFirstBoot=yes erneut ausführen.

getty-pre.target
Eine besondere passive Ziel-Unit. Es wird erwartet, dass Benutzer dieses Zieles sie in
ihrer Hochfahrtransaktion mittels einer Abhängigkeit (d.h. Wants=) hereinziehen.
Sortieren Sie Ihre Unit vor diese Unit, falls Sie die Konsole verwenden wollen, genau
bevor Getty gestartet wird.

local-fs-pre.target
Diese Ziel-Unit wird automatisch vor allen lokalen, mit auto markierten
Einhängepunkten sortiert (siehe oben). Sie kann verwandt werden, um bestimmte Units
vor allen lokalen Einhängungen auszuführen.

network.target
Diese Unit soll anzeigen, wenn die Netzwerkfunktionalität verfügbar ist, aber es ist
nur sehr unscharf definiert, was das bedeuten soll. Allerdings sollte mindestens
Folgendes gelten:

• Beim Hochfahren sollten alle konfigurierten synthetischen Netzwerkgeräte (d.h.
nicht die physischen, die das Auftauchen von Hardware erwarten und untersucht
werden müssen, sondern virtuelle wie Bridge-Geräte und ähnliche, die
programmatisch erstellt werden), die nicht von zugrundeliegender Hardware
abhängen, zum Zeitpunkt, zu dem dieses Ziel erreicht wird, zugewiesen worden sein.
Es ist für diese Schnittstellen nicht notwendig, dass die Konfiguration auf
IP-Ebene abgeschlossen ist, wenn network.target erreicht wird.

• Beim Herunterfahren wird eine Unit, die nach network.target einsortiert ist,
gestoppt, bevor das Netz, auf welcher Stufe auch immer es dann eingerichtet ist,
heruntergefahren wird. Sie ist daher beim Schreiben von Dienstedateien nützlich,
die beim Herunterfahren Netzwerkzugriff benötigen und sich daher nach diesem Ziel
einsortieren, es aber nicht hereinziehen sollten. Siehe auch Dienste ausführen,
nachdem das Netz oben ist[1] für weitere Informationen.

Es muss betont werden, dass beim Hochfahren keinerlei Garantie gegeben werden kann,
dass Hardware-basierte Geräte zum Zeitpunkt des Erreichens dieses Zieles aufgetaucht
sind, oder sogar eine komplette IP-Konfiguration erlangt haben. Verwenden Sie für
diesen Zweck das weiter oben beschriebene Ziel network-online.target.

network-pre.target
Diese passive Ziel-Unit kann durch Dienste, die ausgeführt werden müssen, bevor
irgendein Netz eingerichtet ist, hereingezogen werden, beispielsweise für den Zweck
der Einrichtung einer Firewall. Sämtliche Netzverwaltungssoftware sortiert sich nach
diesem Ziel, zieht es aber nicht herein.

nss-lookup.target
Ein Ziel, das als Synchronisationspunkt für alle Rechner-/Netznamensdienste-Abfragen
verwandt werden sollte. Beachten Sie, dass dies von den Abfragen der
UNIX-Benutzer/-Gruppen unabhängig ist, für Letzteres sollte nss-user-lookup.target
verwandt werden. Alle Dienste, für die die Verfügbarkeit der kompletten
Rechner-/Namensauflösung unverzichtbar ist, sollten sich nach diesem Ziel
einsortieren, es aber nicht hereinziehen. Systemd fügt automatisch Abhängigkeiten der
Art After= für diese Ziel-Unit zu allen SysV-Init-Skripte-Dienste-Units hinzu, bei
denen sich eine LSB-Kopfzeile auf die Einrichtung »$named« bezieht.

nss-user-lookup.target
Ein Ziel, das als Synchronisationspunkt für alle normalen
Unix-Benutzer/-Gruppennamensnachschlagdienste verwandt werden sollte. Beachten Sie,
dass dies von den Rechner-/Netzwerknamensnachschlagungen unabhängig ist, für Letzteres
sollte nss-lookup.target verwandt werden. Alle Dienste, für die die Verfügbarkeit der
kompletten Benutzer-/Gruppendatenbank unverzichtbar ist, sollten nach diesem Ziel
einsortiert werden, es aber nicht hereinziehen. Alle Dienste, die Teile der
Benutzer-/Gruppendatenbank bereitstellen, sollten vor dieses Ziel sortiert werden und
es hereinziehen. Beachten Sie, dass diese Unit nur für reguläre Benutzer und Gruppen
relevant ist, Systembenutzer und -gruppen müssen bereits während der frühsten Phase
des Systemstarts auflösbar sein und benötigen daher keine besondere Sortierung
bezüglich dieses Ziels.

remote-fs-pre.target
Diese Ziel-Unit wird automatisch vor alle Einhängepunkt-Units (siehe oben) und mit
_netdev markierte Cryptsetup-/Veritysetup-Geräte sortiert. Sie kann zur Ausführung
bestimmter Units vor der Eröffnung der fernen verschlüsselten Geräte und
Einhängepunkte verwandt werden. Beachten Sie, dass diese Unit im Allgemeinen nicht
Teil der anfänglichen Transaktion ist, außer wenn die Unit, die vor allen fernen
Einhängungen einsortiert werden möchte, sie mit einer Abhängigkeit der Art Wants=
hereinzieht. Falls die Unit vom Auftauchen der ersten fernen Einhängung hereingezogen
werden möchte, sollte sie network-online.target verwenden (siehe oben).

rpcbind.target
portmapper/rpcbind zieht dieses Ziel herein und sortiert sich davor ein, um seine
Verfügbarkeit anzuzeigen. Systemd fügt automatisch Abhängigkeiten der Art After= für
diese Ziel-Unit zu allen SysV-Init-Skripte-Dienste-Units hinzu, bei denen sich eine
LSB-Kopfzeile auf die Einrichtung »$portmap« bezieht.

time-set.target
Dienste, die für das Setzen der Systemuhr (CLOCK_REALTIME) von einer lokalen Quelle
(wie einer betreuten Zeitstempeldatei oder einer ungenauen Echtzeituhr) verantwortlich
sind, sollten dieses Ziel hereinziehen und sich davor einsortieren. Alle Dienste, bei
denen eine ungefähre, grob monotone Zeit gewünscht ist, sollten sich nach dieser Unit
einsortieren, sie aber nicht hereinziehen.

Dieses Ziel stellt nicht die Genauigkeitszusagen von time-sync.target (siehe unten)
bereit, hängt allerdings nicht davon ab, dass die fernen Uhr-Quellen erreichbar sind,
d.h. das Ziel wird typischerweise nicht durch Netzwerkprobleme und ähnliches
verzögert. Die Verwendung dieses Zieles wird für Dienste empfohlen, bei denen eine
ungefähre Uhrgenauigkeit und grobe Monotonie gewünscht ist, aber die Aktivierung nicht
aufgrund möglicherweise unzuverlässiger Netzwerkkommunikation verzögert werden soll.

Der Diensteverwalter fügt automatisch Abhängigkeiten vom Typ After= für diese
Ziel-Unit an alle Timer-Units mit mindestens einer Direktiven OnCalendar= hinzu.

Der Dienst systemd-timesyncd.service(8) ist ein einfacher Daemon, der dieses Ziel
hereinzieht und sich selbst davor einordnet. Abgesehen von der Implementierung des
SNTP-Netzwerk-Protokolls verwaltet er einen Zeitstempel auf der Platte, dessen
Veränderungszeitpunkt regelmäßig aktualisiert wird. Beim Hochfahren des Dienstes wird
die lokale Systemuhr von dieser Veränderungszeit gesetzt und damit sichergestellt,
dass sie grob monoton zunimmt.

Beachten Sie, dass das Einsortieren einer Unit nach time-set.target nur Wirkung zeigt,
falls es tatsächlich einen Dienst gibt, der davor einsortiert ist und diesen
verzögert, bis die Uhr für grobe Monotonität angepasst wurde. Andernfalls könnte
dieses Ziel erreicht werden, bevor die Uhr angepasst wurde, so dass sie grob monoton
ist. Aktivieren Sie systemd-timesyncd.service(8) oder eine alternative
NTP-Implementierung, um dieses Ziel zu verzögern.

time-sync.target
Dienste, die abgeschlossene Synchronisation der Systemuhr (CLOCK_REALTIME) von einer
fernen Quelle anzeigen, sollten dieses Ziel hereinziehen und sich davor einsortieren.
Alle Dienste, bei denen eine genaue Zeit unverzichtbar ist, sollten sich nach dieser
Unit einsortieren, sie aber nicht hereinziehen.

Der Diensteverwalter fügt automatisch Abhängigkeiten vom Typ After= für diese
Ziel-Unit zu allen SysV-Init-Skripte-Dienste-Units hinzu, bei denen eine LSB-Kopfzeile
auf die Einrichtung »$time« referenziert, sowie auf alle Timer-Units mit mindestens
einer Direktiven OnCalendar=.

Dieses Ziel stellt strengere Uhr-Genauigkeitsgarantien als time-set.target (siehe
oben) bereit, benötigt aber wahrscheinlich Netzwerkkommunikation und führt
unvorhersehbare Verzögerungen ein. Dienste, die Uhrgenauigkeit benötigen und bei denen
Netzwerkkommunikationsverzögerungen akzeptierbar sind, sollten dieses Ziel verwenden.
Dienste, die keine so genaue Uhr und nur ein ungefähres und grob monotones
Uhrverhalten benötigen, sollten stattdessen time-set.target verwenden.

Beachten Sie, dass das Einsortieren einer Unit nach time-sync.target nur Wirkung
zeigt, falls es tatsächlich einen Dienst gibt, der davor einsortiert ist und diesen
verzögert, bis die Uhr-Synchronisierung erreicht wurde. Andernfalls könnte diese Ziel
erreicht werden, bevor die Uhr mit einer fernen, genauen Referenzuhr synchronisiert
wurde. Wenn Sie systemd-timesyncd.service(8) verwenden, aktivieren Sie
systemd-time-wait-sync.service(8), um dieses Ziel zu verzögern. Oder verwenden Sie
einen äquivalenten Dienst für andere NTP-Implementierungen.

Tabelle 1. Vergleich
┌─────────────────────────────────┬──────────────────────────────────┐
│time-set.target │ time-sync.target │
├─────────────────────────────────┼──────────────────────────────────┤
│»schnell« zu erreichen │ »langsam« zu erreichen │
├─────────────────────────────────┼──────────────────────────────────┤
│verwendet typischerweise lokale │ verwendet typischerweise ferne │
│Uhr-Quellen, Systemstartprozess │ Uhr-Quellen, fügt Abhängigkeiten │
│nicht von der Verfügbarkeit │ von fernen Ressourcen in den │
│externer Ressourcen betroffen │ Systemstartprozess ein │
├─────────────────────────────────┼──────────────────────────────────┤
│zuverlässig, da lokal │ unzuverlässig, da │
│ │ typischwerweise Netzwerk │
│ │ involviert │
├─────────────────────────────────┼──────────────────────────────────┤
│garantiert typischerweise nur │ garantiert typischerweise eine │
│eine ungefähre und grob monotone │ genaue Uhr │
│Uhr │ │
├─────────────────────────────────┼──────────────────────────────────┤
│implementiert durch │ implementiert durch │
│systemd-timesyncd.service │ systemd-time-wait-sync.service │
└─────────────────────────────────┴──────────────────────────────────┘

Spezielle Scheiben-Units:
Es gibt vier ».slice«-Units, die die Grundlage der Hierarchie für die Zuweisung von
Ressourcen für Dienste, Benutzer und virtuelle Maschinen oder Container formen. Siehe
systemd.slice(7) für Details über Scheiben-Units.

-.slice
Die Wurzelscheibe ist die Wurzel der Scheiben-Hierarchie. Sie enthält normalerweise
keine Units direkt, kann aber Vorgaben für den gesamten Baum setzen.

system.slice
Standardmäßig können alle durch systemd gestarteten Systemdienste in dieser Scheibe
gefunden werden.

user.slice
Standardmäßig werden alle Benutzerprozesse und -dienste im Auftrag des Benutzers
gestartet, einschließlich der in dieser Scheibe auffindbaren benutzerbezogenen
Instanzen. Sie wird durch systemd-logind.service hereingezogen.

machine.slice
Standardmäßig können alle mit systemd-machined registrierten virtuellen Maschinen und
Container in dieser Scheibe gefunden werden. Sie wird von systemd-machined.service
hereingezogen.

UNITS, DIE VOM BENUTZERDIENSTEVERWALTER VERWALTET WERDEN

Spezielle Benutzer-Units
Wenn Systemd als Benutzerinstanz läuft, sind die folgenden besonderen Units verfügbar:

default.target
Dies ist das Hauptziel der Benutzersitzung und wird standardmäßig gestartet.
Verschiedene Dienste, die die normale Benutzersitzung zusammen bilden, sollten in
dieses Ziel hineingezogen werden. In dieser Hinsicht ist default.target ähnlich zu
multi-user.target in der Systeminstanz, aber es ist eine echte Unit, kein Alias.

Zusätzlich sind die folgenden Units verfügbar, die ähnliche Definitionen wie ihre
System-Gegenstücke haben: exit.target, shutdown.target, sockets.target, timers.target,
paths.target, bluetooth.target, printer.target, smartcard.target, sound.target.

Spezielle passive Benutzer-Units
graphical-session.target
Diese Ziel-Unit ist aktiv, wann immer eine graphische Sitzung läuft. Sie wird zum
Stoppen der Benutzerdienste, die nur in einer graphischen Sitzung (X, Wayland usw.)
gültig sind, wenn die Sitzung beendet wird, verwandt. Solche Dienste sollten ein
»PartOf=graphical-session.target« in ihrem Abschnitt »[Unit]« haben. Ein Ziel für eine
bestimmte Sitzung (z.B. gnome-session.target) startet und stoppt
»graphical-session.target« mit »BindsTo=graphical-session.target«.

Welche Dienste durch ein Sitzungsziel gestartet werden, wird durch die Abhängigkeiten
»Wants=« und »Requires=« bestimmt. Für Dienste, die unabhängig aktiviert werden
können, sollten Symlinks in ».wants/« und ».requires/« verwandt werden, siehe
systemd.unit(5). Diese Symlinks sollten entweder in Paketen ausgeliefert oder
dynamisch nach der Installation hinzugefügt werden, beispielsweise mittels »systemctl
add-wants«, siehe systemctl(1).

Beispiel 1. Nautilus als Teil einer GNOME-Sitzung »gnome-session.target« zieht
Nautilus als Dienst oberster Stufe herein:

[Unit]
Description=Benutzer-Systemd-Dienst für die graphische GNOME-Sitzung
Wants=nautilus.service
BindsTo=graphical-session.target

»nautilus.service« wird gestoppt, wenn die Sitzung stoppt:

[Unit]
Description=Darstellung des Desktop-Icons mit Nautilus
PartOf=graphical-session.target

[Service]
…

graphical-session-pre.target
Dieses Ziel enthält Dienste, die die Umgebung oder globale Konfigurationen einer
graphischen Sitzung einrichten, wie SSH/GPG-Agenten (die eine Umgebungsvariable an
alle Desktop-Prozesse exportieren müssen) oder die veraltete D-conf-Schlüssel nach
einem Betriebssystem-Upgrade migrieren (was passieren muss, bevor irgendein Prozess,
der sie verwenden könnte, gestartet wird). Dieses Ziel muss vor dem Start einer
graphischen Sitzung wie gnome-session.target gestartet werden.

xdg-desktop-autostart.target
Die XDG-Spezifikation definiert eine Art, Anwendungen mittels XDG-Desktop-Dateien
automatisch zu starten. Systemd liefert systemd-xdg-autostart-generator(8) für die
XDG-Desktop-Dateien in Verzeichnissen für automatischen Start. Desktop-Umgebungen
können diesen Dienst nach Wunsch verwenden, indem sie eine Wants=-Abhängigkeit auf
xdg-desktop-autostart.target hinzufügen.

Spezielle Benutzer-Scheiben-Units:
Es gibt vier ».slice«-Units, die die Grundlage der Benutzer-Hierarchie für die Zuweisung
von Ressourcen für Benutzeranwendungen und -dienste formen. Siehe systemd.slice(7) für
Details über Scheiben-Units und die Dokumentation über Desktop-Umgebungen[3] für weitere
Informationen.

-.slice
Die Wurzelscheibe ist die Wurzel der Benutzer-Scheiben-Hierarchie. Sie enthält
normalerweise keine Units direkt, kann aber Vorgaben für den gesamten Baum setzen.

app.slice
Standardmäßig werden alle von systemd verwalteten Benutzerdienste und -Anwendungen in
dieser Scheibe angetroffen. Alle interaktiv gestarteten Anwendungen wie Web-Browser
und Texteditoren sowie nicht kritische Dienste sollten in diese Scheibe abgelegt
werden.

session.slice
Alle für die Sitzung benötigten unentbehrlichen Dienste und Anwendungen sollten diese
Scheibe verwenden. Dies sind Dienste, die entweder nicht leicht neu gestartet werden
können oder bei den Verzögerungsproblematiken die Interaktivität des Systems und der
Anwendungen betreffen könnte. Hierzu gehört der Display-Server,
Bildschirmvorleseprogramme und andere Dienste wie DBus oder XDG-Portale. Solche
Dienste sollten durch Hinzufügen von Slice=session.slice zu ihren Unit-Dateien als
Teil dieser Scheibe konfiguriert werden.

background.slice
Alle Dienste, die Hintergrundaufgaben mit niedriger Priorität ausführen, sollten diese
Schreibe verwenden. Damit werden Ressourcen bevorzugt anderen Scheiben zugeteilt. Als
Beispiele seien nichtinteraktive Aufgaben wie die Indexierung von Dateien oder
Sicherungsaktionen genannt, bei denen Verzögerungen keine Rolle spielen.

SIEHE AUCH

       systemd(1), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.target(5),
       systemd.slice(5), bootup(7), systemd-fstab-generator(8), user@.service(5)

ANMERKUNGEN

        1. Dienste ausführen, nachdem das Netz hochgefahren ist
           https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

        2. Syslog-Schnittstelle
           https://www.freedesktop.org/wiki/Software/systemd/syslog

        3. Desktop-Umgebungen
           https://systemd.io/DESKTOP_ENVIRONMENTS

Ü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 Copyright-
       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⟩.