Ich habe gelesen, dass es zwei Ordner für Unit-Dateien gibt (nicht im Benutzermodus).
/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator
Im Widerspruch zu diesem Verständnis steht die Antwort auf diese Frage:How to write startup script for Systemd. Kann jemand die fehlenden Informationen ergänzen, damit ich verstehe, was los ist? (UPDATE:Die Antwort wurde aktualisiert, und mein Verständnis widerspricht ihr nicht mehr. )
Außerdem scheinen die Skripte in Unterordnern innerhalb von /etc/systemd/system/ organisiert zu sein Ordner:
getty.target.wants
multi-user.target.wants
An einem anderen Ort habe ich gelesen, dass es noch andere Orte gibt. Es scheint, dass diese für benutzerspezifische Dienste sind.
/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.
Aktualisierung 31.08.2015:
Für andere ist hier ein Link zu einer verwandten Frage, die ich kürzlich gestellt habe:Wo lege ich Skripte ab, die von systemd-Einheiten ausgeführt werden?
Akzeptierte Antwort:
Der beste Platz für System Unit-Dateien: /etc/systemd/system Stellen Sie einfach sicher, dass Sie ein Ziel im Abschnitt [Installieren] hinzufügen, lesen Sie „Woher weiß es?“. für Details. AKTUALISIEREN :/usr/local/lib/systemd/system ist eine weitere Option, lesen Sie „Graubereich“ für weitere Einzelheiten.“
Der beste Ort, um Benutzer abzulegen Unit-Dateien: /etc/systemd/user oder $HOME/.config/systemd/user aber es hängt von den Berechtigungen und der Situation ab.
Die Wahrheit ist, dass systemd-Units (oder wie der Einführungssatz sie nennt, „Unit-Konfigurationen“) überall eingesetzt werden können – vorausgesetzt, Sie sind bereit, manuelle Symlinks zu erstellen, und Sie sind sich der Einschränkungen bewusst. Es macht das Leben einfacher, die Unit dort abzulegen, wo systemctl daemon-reload kann es aus guten Gründen finden:
- Die Verwendung eines Standardspeicherorts bedeutet, dass systemd-Generatoren sie finden und sie beim Booten einfach mit
systemctl enableaktivieren können . Das liegt daran, dass Ihre Unit automatisch zu einem Unit-Abhängigkeitsbaum (einem Unit-Cache) hinzugefügt wird. - Sie müssen sich keine Gedanken über Berechtigungen machen, da nur die berechtigten Benutzer in die gekennzeichneten Bereiche schreiben können.
Woher weiß es das?
Und wie genau aktiviert systemctl enable Wissen Sie, wo Sie den Symlink erstellen können? Sie codieren es fest innerhalb der Unit
selbst unter [install] Sektion. Normalerweise gibt es eine Zeile wie
[Install]
WantedBy = multi-user.target
das entspricht einem vordefinierten Ort im Dateisystem.
Auf diese Weise systemctl enable weiß, dass diese Unit von einer Gruppe von Unit-Dateien namens multi-user.target abhängig ist („Ziel“ ist der Begriff, der verwendet wird, um Unit-Abhängigkeitsgruppen zu bezeichnen. Sie können alle Gruppen mit systemctl list-units --type target auflisten ). Die Gruppe von Unit-Dateien, die mit einem Ziel geladen werden sollen, wird in targetname.target.wants abgelegt Verzeichnis. Dies ist nur ein Verzeichnis voller Symlinks (oder das Original). Wenn Ihr [Install] Abschnitt sagt, dass es WantedBy ist das multi-user.target , aber wenn kein Symlink darauf in multi-user.target.wants existiert Verzeichnis, dann wird es nicht geladen. Wenn die systemd-Unit-Generatoren Ihre Unit-Datei beim Booten zum Abhängigkeitsbaum-Cache hinzufügen (Sie können Generatoren manuell mit systemctl daemon-reload auslösen ), weiß es automatisch, wo der Symlink abgelegt werden muss – in diesem Fall im Verzeichnis /etc/systemd/system/multi-user.target.wants/ sollten Sie es aktivieren.
Schlüsselpunkte im Handbuch:
Zusätzliche Units können aus
Verzeichnissen, die sich nicht im Unit-Ladepfad befinden, in systemd („verlinkt“) geladen werden. Siehe Link-Befehl für
systemctl(1).
Suchen Sie unter systemctl nach Unit File Commands
Ladepfad der Unit-Datei
Bitte lesen und verstehen Sie den ersten Satz im folgenden Zitat aus man systemd.unit (weil es impliziert, dass alle Pfade, die ich hier erwähne, möglicherweise nicht auf Sie zutreffen, wenn Ihr systemd mit anderen Pfaden kompiliert wurde):
Unit-Dateien werden aus einer Reihe von Pfaden geladen, die während der Kompilierung festgelegt wurden, wie in den beiden Tabellen unten beschrieben. Unit-Dateien, die in früher aufgelisteten Verzeichnissen gefunden wurden, überschreiben Dateien mit demselben Namen in Verzeichnissen weiter unten in der Liste.
Wenn die Variable $SYSTEMD_UNIT_PATH gesetzt ist, überschreibt der Inhalt dieser Variablen den Unit-Load-Pfad. Wenn $SYSTEMD_UNIT_PATH mit einer leeren Komponente („:“) endet, wird der übliche Unit-Load-Pfad an den Inhalt der Variablen angehängt.
Tabelle 1 und Tabelle 2 aus man systemd.unit sind gut.
Pfade laden, wenn im Systemmodus ausgeführt wird (--system ).
/etc/systemd/systemLokale Konfiguration/run/systemd/systemLaufzeiteinheiten/usr/lib/systemd/systemEinheiten installierter Pakete (oder/lib/systemd/systemLesen Sie in einigen Fällenman systemd.unit)
Pfad laden, wenn im Benutzermodus ausgeführt wird (--user )
Es gibt einen Unterschied zwischen pro Benutzer Einheiten und all/global Benutzereinheiten.
Benutzerabhängig
-
$XDG_CONFIG_HOME/systemd/userBenutzerkonfiguration (wird nur verwendet, wenn$XDG_CONFIG_HOMEeingestellt ist) -
$HOME/.config/systemd/userBenutzerkonfiguration (wird nur verwendet, wenn$XDG_CONFIG_HOMEnicht gesetzt) -
$XDG_RUNTIME_DIR/systemd/userLaufzeiteinheiten (wird nur verwendet, wenn$XDG_RUNTIME_DIReingestellt ist) -
$XDG_DATA_HOME/systemd/userEinheiten von Paketen, die im Home-Verzeichnis installiert wurden (wird nur verwendet, wenn$XDG_DATA_HOMEeingestellt ist) -
$HOME/.local/share/systemd/userEinheiten von Paketen, die im Home-Verzeichnis installiert wurden (wird nur verwendet, wenn$XDG_DATA_HOMEnicht gesetzt)
--global (alle Benutzer)
Einheiten, die für alle Benutzer gelten – also auch jedem Benutzer gehören. Daher kann jeder Benutzer diese Dienste stoppen, selbst wenn ein Administrator sie beim Booten aktiviert.
/etc/systemd/userLokale Konfiguration für alle Benutzer (systemctl --global enable userunit.service)/usr/lib/systemd/userEinheiten von Paketen, die systemweit für alle Benutzer installiert wurden (oder/lib/systemd/systemin einigen Fällen lesen Sie man systemd.unit)/run/systemd/userLaufzeiteinheiten
Graubereich
Einerseits spezifiziert der File Hierarchy Standard, dass /etc ist für lokale Konfigurationen, die keine Binärdateien ausführen. Andererseits
gibt es an, dass /usr/local/ „wird vom Systemadministrator bei der lokalen Installation von Software verwendet“. Sie könnten auch argumentieren (wenn auch nicht nur aus organisatorischen Gründen), dass alle System-Unit-Dateien unter /usr/local/lib/systemd/system abgelegt werden sollten , aber dies ist für Unit-Dateien gedacht, die Teil von „Software“ sind, nicht von einem Paketmanager.
Die entsprechenden systemd-Benutzereinheiten, die systemweit sind, könnten unter /usr/local/lib/systemd/user .
Transiente Einheit
Ein weiterer vergessener Ort ist nirgendwo! Ein vielleicht weniger bekanntes Programm ist systemd-run . Sie können es verwenden, um transiente Einheiten im laufenden Betrieb auszuführen. siehe man systemd-run .
Um beispielsweise morgen früh um 4 Uhr einen Neustart zu planen (möglicherweise benötigen Sie --force um sicherzustellen, dass ein Neustart erfolgt):
systemd-run -u restart --description="Restarts machine" --on-calendar="2020-12-18 00:04:00" systemctl --force reboot
Dies ergibt eine transiente Unit-Datei restart.service und einen entsprechenden Timer (wegen der --on-calendar , angezeigt durch transient=yes .
/run/systemd/transient/restart.service
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=Restarts machine
[Service]
ExecStart=
ExecStart="/usr/bin/systemctl" "--force" "reboot"
Beachten Sie, dass es auch die gefährlichere Double-Force-Option --force --force gibt , was den Kernel anweist, sofort anzuhalten (und, wenn Sie nicht wissen, was Sie tun, unsicher, weil es fast gleichbedeutend mit einer Stromunterbrechung ist).