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

Diesem Verständnis widerspricht die folgende Antwort: https://unix.stackexchange.com/a/47715/33386 . Kann jemand die fehlenden Informationen eintragen, damit ich verstehe, was los ist? ( UPDATE: Die Antwort wurde aktualisiert und mein Verständnis steht nicht mehr im Widerspruch dazu. )

Außerdem scheinen die Skripte in Unterordnern innerhalb des /etc/systemd/system/Ordners angeordnet zu sein:

getty.target.wants
multi-user.target.wants

An einem anderen Ort habe ich gelesen, dass es andere Orte gibt. Es scheint, dass dies 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.

Update 2015-08-31:

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 units ausgeführt werden?

Der beste Ort, um System- Unit-Dateien abzulegen: /etc/systemd/system Stellen Sie sicher, dass Sie im Abschnitt [Install] ein Ziel hinzufügen. Lesen Sie "Woher weiß es das?" für Details. UPDATE : Ist/usr/local/lib/systemd/system eine andere Option, lesen Sie "Gray Area" für Details. "

Der beste Ort, um User- Unit-Dateien abzulegen: /etc/systemd/user oder $HOME/.config/systemd/user aber es hängt von den Berechtigungen und der Situation ab.

Die Wahrheit ist, dass systemd-Einheiten (oder wie der Intro-Satz sie nennt, "Einheitenkonfigurationen") überall hingehen können - vorausgesetzt, Sie sind bereit, manuelle Symlinks zu erstellen, und Sie sind sich der Vorbehalte bewusst. Es macht das Leben leichter, das Gerät systemctl daemon-reloadaus guten Gründen dort aufzustellen, wo es zu finden ist:

• Die Verwendung eines Standardverzeichnisses bedeutet, dass systemd-Generatoren sie finden und beim Booten leicht aktivieren können systemctl enable. Dies liegt daran, dass Ihre Einheit automatisch einem Einheitenabhängigkeitsbaum (einem Einheiten-Cache) hinzugefügt wird.
• Sie müssen nicht über Berechtigungen nachdenken, da nur die richtigen privilegierten Benutzer in die festgelegten Bereiche schreiben können.

Woher weiß es das?

Und wie genau weiß systemctl enable, wo der Symlink erstellt werden soll? Sie können es in der Einheit selbst unter dem [install]Abschnitt fest codieren . Normalerweise gibt es eine Linie wie

[Install]
WantedBy = multi-user.target

das entspricht einem vordefinierten Ort im Dateisystem. Auf diese Weise systemctlwissen Sie, dass diese Einheit von einer Gruppe von Einheitendateien abhängt, die als multi-user.target"Ziel" bezeichnet wird. Sie können alle Gruppen mit systemctl list-units --type targetauflisten. Die Gruppe von Unit-Dateien, die mit einem Ziel geladen werden sollen, wird in ein targetname.target.wantsVerzeichnis gestellt. Dies ist nur ein Verzeichnis voller Symlinks (oder der echten). Wenn in Ihrem [Install]Abschnitt angegeben ist , dass dies der Fall ist, WantedByder multi-user.targetSymlink jedoch nicht im multi-user.target.wantsVerzeichnis vorhanden ist, wird er nicht geladen. Wenn die systemd-Unit-Generatoren Ihre Unit-Datei beim Booten zum Abhängigkeitsbaum-Cache hinzufügen (Sie können Generatoren mit manuell auslösen systemctl daemon-reload), weiß sie automatisch, wo der Symlink abgelegt werden muss - in diesem Fall im Verzeichnis/etc/systemd/system/multi-user.target.wants/ sollten Sie es aktivieren.

Wichtige Punkte im Handbuch:

Zusätzliche Einheiten können aus Verzeichnissen, die sich nicht im Pfad zum Laden von Einheiten befinden, in systemd ("verknüpft") geladen werden. Siehe den Link-Befehl für systemctl (1).

Suchen Sie unter systemctl nach Unit File Commands

Unit File Load Path

Unit-Dateien werden aus einer Reihe von Pfaden geladen, die während der Kompilierung festgelegt wurden. Eine Beschreibung finden Sie in den beiden folgenden Tabellen. Gerätedateien, die in den zuvor aufgelisteten Verzeichnissen gefunden wurden, überschreiben Dateien mit demselben Namen in den Verzeichnissen weiter unten in der Liste.

Wenn die Variable festgelegt $SYSTEMD_UNIT_PATHist, überschreibt der Inhalt dieser Variablen den Pfad für die Ladeeinheit. Wenn $SYSTEMD_UNIT_PATHmit einer leeren Komponente (":") geendet wird, wird der übliche Ladepfad an den Inhalt der Variablen angehängt.

Tabelle 1 und Tabelle 2 man systemd.unitsind gut.

Laden Sie Pfade, wenn Sie im Systemmodus ( --system) ausgeführt werden.

• /etc/systemd/system Lokale Konfiguration
• /run/systemd/system Laufzeiteinheiten
• /usr/lib/systemd/system Einheiten der installierten Pakete

Ladepfad bei Ausführung im Benutzermodus ( --user)

Es gibt einen Unterschied zwischen Einheiten pro Benutzer und Einheiten aller / globaler Benutzer.

Benutzerabhängig

• $XDG_CONFIG_HOME/systemd/user Benutzerkonfiguration (nur verwendet wenn $XDG_CONFIG_HOMEgesetzt)
• $HOME/.config/systemd/user Benutzerkonfiguration (nur verwendet, wenn $XDG_CONFIG_HOMEnicht festgelegt)

• $XDG_RUNTIME_DIR/systemd/user Runtime Units (nur verwendet wenn $XDG_RUNTIME_DIRgesetzt)

• $XDG_DATA_HOME/systemd/user Einheiten von Paketen, die im Ausgangsverzeichnis installiert wurden (nur verwendet, wenn $XDG_DATA_HOMEfestgelegt)

• $HOME/.local/share/systemd/user Einheiten von Paketen, die im Ausgangsverzeichnis installiert wurden (nur verwendet, wenn $XDG_DATA_HOMEnicht festgelegt)

--global (Alle Nutzer)

Einheiten, die für alle Benutzer gelten - dh auch für jeden Benutzer. So kann jeder Benutzer diese Dienste beenden, auch wenn sie beim Booten von einem Administrator aktiviert werden.

• /etc/systemd/user Lokale Konfiguration für alle Benutzer ( systemctl --global enable userunit.service)
• /usr/lib/systemd/user Paketeinheiten, die systemweit für alle Benutzer installiert wurden
• /run/systemd/user Laufzeiteinheiten

Grauzone

Zum einen legt der File Hierarchy Standard fest, dass /etclokale Konfigurationen keine Binärdateien ausführen. Andererseits gibt es an, dass /usr/local/"vom Systemadministrator verwendet wird, wenn Software lokal installiert wird". Sie könnten auch argumentieren (wenn auch nicht nur zum Zweck der Organisation), dass alle System-Unit-Dateien darunter fallen sollten /usr/local/lib/systemd/system, aber dies ist für Unit-Dateien gedacht, die Teil von "Software" sind und nicht von einem Package Manager stammen. Die entsprechenden systemd Benutzereinheiten, die systemweit sind, könnten darunter fallen /usr/local/lib/systemd/user.

/etc/systemd/systemist , wo Sie setzen Ihre Skripte, setzt Pacman Paket Skripte in /usr/lib/systemd/system.

Beim Ausgeben systemctl enable foo.servicewerden Symlinks von /usrbis erstellt /etc. Weitere Informationen finden Sie im Abschnitt Pfad zum Laden von Einheiten man systemd.unit(5).

Ich habe 3 geschrieben, eine für ntpdeine für eine zweite, statische Ethernet-Karte und eine für die Ausführung p0f, die passive Betriebssystemkennung. Ich habe sie alle reingelegt /etc/systemd/system. Sieht so aus, als könnte ich vielleicht systemddas NTP-Zeug erledigen lassen , aber ich glaube nicht, dass ich mich so sehr darauf verlassen möchte.