- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SYSTEMD.SPECIAL(7) | systemd.special | SYSTEMD.SPECIAL(7) |
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
basic.target
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
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
cryptsetup.target
veritysetup.target
dbus.service
dbus.socket
default.target
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
emergency.target
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
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
final.target
getty.target
graphical.target
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
hybrid-sleep.target
suspend-then-hibernate.target
halt.target
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
initrd.target
initrd-fs.target
initrd-root-device.target
initrd-root-fs.target
initrd-usr-fs.target
kbrequest.target
kexec.target
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
machines.target
multi-user.target
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
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
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
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
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
remote-veritysetup.target
remote-fs.target
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
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
shutdown.target
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
sleep.target
slices.target
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
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
swap.target
sysinit.target
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
system-update.target, system-update-pre.target, system-update-cleanup.service
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
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
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
Dies kann dazu verwandt werden, dynamisch Bluetooth-Verwaltungs-Daemons hereinzuziehen, wenn Bluetooth-Hardware gefunden wird.
printer.target
Dies kann dazu verwandt werden, dynamisch Druckerverwaltungs-Daemons hereinzuziehen, wenn Drucker-Hardware gefunden wird.
smartcard.target
Dies kann zum dynamischen Hereinziehen von Smartcard-Verwaltungs-Daemons verwandt werden, wenn Smartcard-Hardware gefunden wird.
sound.target
Dies kann zum dynamischen Hereinziehen von Audio-Verwaltungs-Daemons verwandt werden, wenn Audio-Hardware gefunden wird.
usb-gadget.target
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
cryptsetup-pre.target
veritysetup-pre.target
first-boot-complete.target
getty-pre.target
local-fs-pre.target
network.target
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
nss-lookup.target
nss-user-lookup.target
remote-fs-pre.target
rpcbind.target
time-set.target
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
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 Uhr-Quellen, Systemstartprozess nicht von der Verfügbarkeit externer Ressourcen betroffen | verwendet typischerweise ferne Uhr-Quellen, fügt Abhängigkeiten von fernen Ressourcen in den Systemstartprozess ein |
zuverlässig, da lokal | unzuverlässig, da typischwerweise Netzwerk involviert |
garantiert typischerweise nur eine ungefähre und grob monotone Uhr | garantiert typischerweise eine genaue Uhr |
implementiert durch systemd-timesyncd.service | implementiert durch 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
system.slice
user.slice
machine.slice
UNITS, DIE VOM BENUTZERDIENSTEVERWALTER VERWALTET WERDEN¶
Spezielle Benutzer-Units¶
Wenn Systemd als Benutzerinstanz läuft, sind die folgenden besonderen Units verfügbar:
default.target
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
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
xdg-desktop-autostart.target
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
app.slice
session.slice
background.slice
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
- 2.
- Syslog-Schnittstelle
- 3.
- Desktop-Umgebungen
Ü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 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.
systemd 252 |