[ Main | Local ]

Eine Unit ist jegliche Art von Resource, die Systemd verwalten kann: Services, Netzwerk-Resourcen, Devices, Mounts ... Das Unit-File beschreibt, wie genau das gemacht werden soll.

Unit-Files werden in der Regel nach /lib/systemd/system kopiert. Diese werden nicht modifiziert. Änderungen legt man in /etc/systemd/system an. Dort gespeicherte Files haben Priorität über die System Unit-Files. Falls in /lib/systemd/system kein File existiert, so wird dort ein Link erzeugt.

Weiterhin kann man einzelne Setzungen überspielen oder Ergänzungen hinzufügen. Dazu legt man im Verzeichnis /etc/systemd/system ein neues Verzeichnis an, welches wie das Unit-File heisst - allerdings mit einem .d am Ende (für die Unit gpsd.service wäre das zB. gpsd.service.d). In diesem Verzeichnis erzeugt man ein .conf File (der Name ist unerheblich, aber die Endung ist wichtig). In diese File werden alle Änderungen und Ergänzungen eingetragen (ein sogenanntes Snippet).

Der Systemd legt ausserdem noch Unit-Files in /run/systemd/system für die Dauer der Session an.

Welche Typen von Units gibt es?

Der Typ einer Unit wird durch den zweiten Teil des Namens des Unit-Files angezeigt. Die wichtigsten Typen sind folgende:

• .service: eine Applikation, ein Service oder Daemon - wie damit umgegangen werden soll.
• .socket: ein Netzwerk, Unix socket oder FIFO Puffer. Braucht einen Service, der den Socket öffnet.
• .device: ein Device, was von Systemd verwaltet werden soll, zB. bei einem Mount.
• .target: Eine Liste von Units, die zusammen einen bestimmten Zustand des Systems beschreiben. Vergleichbar mit einem Runlevel.
• .mount: ein von Systemd verwalteter Mountpoint. Im Unit-Namen steht der Pfad, die Schrägstriche durch Bindestriche ersetzt.

Es gibt noch eine Reihe weiterer Typen:

• .path: ist ein Zusatz zu einem .service, welcher ausgeführt wird, wenn es im entsprechenden Pfad eine Aktion gab.
• .timer: ist ein Zusatz zu einer anderen Unit, und funktioniert wie ein Cron-Job.
• .snapshot: können erzeugt werden als Backup des Systemd für einen Rollback bei Änderungen.
• .automount: ist ein Zusatz für einen .mount, wenn das FS automatisch gemounted werden soll.
• .swap: Beschreibt einen swap Space auf dem System.

Zum Schluss gibt es noch .slice und .scope. Damit können Resourcen Control Groups zugeordnet werden sowie externe Processe über den Systemd verwaltet werden.

Wie ein Unit-File aufgebaut ist

Das File besteht aus einer Reihe Sektionen mit definierten Namen. Diese werden in eckigen Klammern geschrieben. Danach folgen aller Parameter der Sektion als Key-Value Paare.

Häufig braucht man folgende Sektionen:

• [Unit] - allgemeine Daten zur Unit und das Verhältnis zu anderen Units.
• [Install] - erlaubt es, die Unit zu "enablen". Diese Sektion beschreibt, was dabei passieren muss.
• [Service] - spezifische Daten zur einer Unit von diesem Typ
• [Timer] - spezifische Daten zur einer Unit von diesem Typ
• [Socket] - spezifische Daten zur einer Unit von diesem Typ
• [Path] - spezifische Daten zur einer Unit von diesem Typ
• [Mount] - spezifische Daten zur einer Unit von diesem Typ

Die "Unit" Sektion ist immer da, "Install" nur dann, wenn man die Unit auch "enablen" können muss. Die "Install" Unit steht dabei immer als letzte Definition. Dazwischen werden dann die spezifischen Sektionen eingetragen.

Folgende Units haben keine spezifische Sektion: "target", "snapshot", "device", "scope".

Die [Unit] Sektion

Es gibt eine Reihe Parameter für die meisten Sektionen. Hier wird eine rein subjective Auswahl der häufigsten Parameter gegeben.

• Description - eine Beschreibung, die im Logging etc. auftaucht.
• Documentation - Man kann URLs zur Dokumentation hinterlegen, die auch angezeigt werden.
• Requires - zeigt eine Reihe Units, die erfolgreich aktiviert sein müssen, sonst wird diese Unit fehlerhaft starten. Dabei werden alle Units parallel gestartet, und das Ergebnis abgefragt.
• BindsTo - wie "Requires", wird aber zusätzlich gestoppt, wenn die genannte Unit gestoppt wird.
• Wants - zeigt eine Reihe Units, die erfolgreich aktiviert sein sollten. Wenn nicht, startet diese Unit trotzdem fehlerfrei.
• Before - zusätzlich zu einem der Einträge von oben. Die gelisteten Units werden nach der aktuellen Unit gestartet.
• After - zusätzlich zu einem der Einträge von oben. Die gelisteten Units werden vor der aktuellen Unit gestartet.
• Conflicts - zeigt Units, die nicht zusammen laufen können. Wird die aktuelle Unit gestartet, werden die Gelisteten gestoppt.
• Condition ... - man kann der Start einer Unit von Bedingungen abhängig machen. Wird die Kondition nicht getroffen, wird die aktuelle Unit übersprungen.
• Assert ... - wie oben, aber wenn die Kondition nicht erfüllt wird, ist auch die aktuelle Unit fehlerhaft.

Die [Install] Sektion

Units mit dieser Sektion werden automatisch gestartet.

• WantedBy - drückt eine Abhängigkeit zwischen Units aus. Die aktuelle Unit wird bei den gelisteten Units in einem Verzeichnis mit dem Namen unitname.type.wants verlinkt.
• RequiredBy - wie oben, das Verzeichnis heisst aber unitname.type.required und die aktuelle Unit "failed", wenn die verlinkte nicht startet.
• Alias - man kann diese Unit auch inter diesem Namen aktivieren, wenn man zB. festgelegt Namen für einen Dienst hat.
• Also - dient dazu, verschiedene Units in Gruppen zusammen zufassen. Die gelisteten Units werden gemeinsam behandelt.

Die [Service] Sektion

Spezifiziert das Verhalten des Service, also welche Prozesse laufen sollen und wie diese abzufragen sind. Wichtig ist der Typ des Service, dessen Parameter Type daher eine Reihe Werte hat:

• simple - einfach ein Prozess, der gestartet wird. Die Unit kommuniziert nicht direkt mit dem Servie, meistens gibt es eine andere Unit dafür, zB: einen Socket.
• forking - der Service spaltet beim Start einen Prozess ab, der dann die Arbeit macht. Systemd übernimmt die neue PID.
• PIDFile - gibt in Verbindung mit "forking" den Pfad zum PID File, damit Systemd den Prozess überwachen kann.
• oneshot - der Prozess wird nur kurz leben, etwas tun und sich dann beenden. Systemd soll das abwarten, und erst dann weitermachen.
• RemainAfterExit - zeigt an, dass Systemd den Prozess als aktiv annehmen soll, auch wenn er sich beendet hat. Meistens mit "oneshot".
• dbus - die Unit wird einen Dienst auf dem D-Bus übernehmen. Systemd macht dann weiter.
• BusName - hier wird der Name des D-Bus für "dbus" gesetzt.
• notify - der Service wird sich melden, wenn er erfolgreich gestartet ist. Systemd macht dann weiter.
• NotifyAccess - spezifiziert den Socket, auf dem gehört werden soll.
• idle - der Service wird erst loslaufen, wenn alle

Neben der Art des Services muss noch definiert werden, wie dieser behandelt werden soll:

• ExecStart - der Pfad und alle Argumente, um den Prozess zu starten. Stellt man einen "-" vor den Pfad, so werden die Return-Codes ignoriert.
• ExecStartPre - man kann mehrere, vorgelagerte Prozesse starten.
• ExecStartPost - man kann mehrere, nachgelagerte Prozesse starten.
• ExecReload - falls ein "reload" möglich ist, kann man hier ein dafür geeignetes Kommando eintragen.
• ExecStop - ein Kommando, mit dem der Service angehalten wird. Sonst wird einfach die PID "gekillt".
• ExecStopPost - einige Kommandos, die nach dem Stop des Service laufen sollen.
• Restart - definiert, unter welchen Umständen der Service automatisch "restartet" wird. Mögliche Werte sind ¿always¿, ¿on-success¿, ¿on-failure¿, ¿on-abnormal¿, ¿on-abort¿, ¿on-watchdog¿.
• RestartSec - ein Timeout, nachdem ein Restart versucht wird.
• TimeoutStartSec - ein Timeout, der nach dem Start abgewartet wird, bevor der Start als "failed" angesehen wird.
• TimeoutStopSec - ein Timeout, der nach dem Stop abgewartet wird, bevor der Prozess gekillt wird.
• TimeoutSec - ein gemeinsamer Timeout für beide Fälle.

Die [Socket] Sektion

Ein Socket hat immer einen passenden Service, der in dem Moment aktiv wird, wenn der Socket angesprochen wird. Für einen Service ist es vorteilhaft, über einen Socket zu kommunizieren, da so Multiplexing gut möglich ist.

• ListenStream - ein Socket, der einen sequentiellen, verlässlichen Datenstrom ermöglicht, zB. ein TCP Socket.
• ListenDatagram - ein Socket, der unabhängige, und nicht verlässliche Datenpakete verarbeiten kann, zB. UDP.
• ListenSequentialPacket - ein Socket, der einen sequentiellen, verlässlichen Datenstrom ermöglicht, aber mit fester Größe der Datagramme, zB. Unix Sockets.
• ListenFIFO - man kann auch einen FIFO Puffer benutzen, statt eines Socket.
• Accept - wird der Socket Verbindungen von verschiedenen Instanzen des Service zulassen? Per Default geht nur eine Instanz.
• SocketUser - für einen Unix Socket kann man hier den Owner spezifizieren. Per Default ist das User "root".
• SocketGroup - wie oben für die Gruppe.
• SocketMode - setzt bei einem Unix Socket oder einem FIFO die Permissions.
• Service - wenn Service und Socket unterschiedliche Namen haben, kann man hier den zugeordneten Service spezifizieren.

Die [Mount] Sektion

Mit Mount Units kann Systemd auch Mount-Points verwalten. Der Name der Unit ist dabei vom Pfad abgeleitet, bei dem alle Schrägstriche durch Bindestriche ersetzt sind.

• What - absoluter Pfad des Mounts.
• Where - absoluter Pfad des Mount-Points. Das ist auch der Name der Unit, mit der Ersetzung mit Bindestrichen.
• Type - der Filesystem Typ.
• Options - die Mount-Optionen (mit Komma separiert).
• DirectoryMode - die Permissions für den Mountpoint, wenn Systemd den einrichten muss.
• TimeoutSec - ein Timeout, nach dessen Ablauf der Mount als "failed" gilt.

Die [Automount] Sektion

Diese Sektion erscheint nur zusammen mit einer Mount-Sektion, falls ein Mount automatisch erfolgen soll.

• Where - absoluter Pfad des (Auto-)Mountpoints, den der Automouter überwachen soll.
• DirectoryMode - die Permissions für den (Auto-)Mountpoint, wenn Systemd den einrichten muss.

Die [Timer] Sektion

Man kann einer Unit eine Timer Unit zuordnen, was eine Funktionalität wie die von Cron bringt.

• Unit - setzt die betroffene Unit. Ist nichts definiert, nimmt Systemd den Namen des Timers + .service.
• OnBootSec - Timeout nach dem Boot, bevor die betroffene Unit aktiviert wird.
• OnActiveSec - Timeout nach dem Start der Timer Unit, bevor die betroffene Unit gestarted wird.
• OnStartupSec - Timeout nach dem Start des Systemd, bevor die betroffene Unit aktiviert wird.
• OnUnitActiveSec - Timeout bezogen auf den letzten Start der betroffenen Unit.
• OnUnitInactiveSec - Timeout bezogen auf den letzten Stop der betroffenen Unit.
• OnCalendar - Angabe eines konkreten Moments, zu dem die betroffene Unit gestartet werden soll.
• AccuracySec - per Default ist der Time auf die Minute genau. Höhere Präzision kann man hier einstellen.
• Persistent - wenn der Time nicht lief, und während der Inaktivität Units hätten gestartet werden müssen, so wird das getan, wenn der Timer hochkommt.
• WakeSystem - hiermit kann man ein System aus dem Suspended Mode holen.

Die [Path] Sektion

Funktioniert ähnlich wie ein Socket. Man teilt dem Systed einen Pfad mit, der überwacht wird. Auch hier muss es eine Unit geben, die dann aktiviert wird.

• PathExists - prüft, ob der angegebene Pfad existiert - dann wird die zugeordnete Unit aktiviert. Das gibt es auch mit Wildcards: PathExistsGlob.
• PathChanged - prüft, ob der Pfad geändert wurde (also ob das angegeben File geschlossen wurde).
• PathModified - wie oben, aber auch bei jedem Schreib-Zugriff.
• DirectoryNotEmpty - sobald ein File im Verzeichnis erscheint, wird aktiviert.
• Unit -
• Unit - setzt die betroffene Unit. Ist nichts definiert, nimmt Systemd den Namen des Path + .service.
• MakeDirectory - der konfigurierte Pfad wird angelegt.
• DirectoryMode - spezifiziert die Permission etc. für den konfigurierten Pfad.

Weitere Sektionen

Es gibt noch eine eigene Sektion für einen Swap-Bereich, sowie eine Sektion, mit der man "Slices" definieren kann, um seine vom Systemd verwalteten Resourcen weiter zu gruppieren.

Units aus einem Template generieren

Man kann ein Template vorgeben, indem alle Werte der Parameter durch Variablen ersetzt sind. So ist es möglich, dynamisch Units zu erzeugen und anzustarten.

Ein solches Template für ein Unit-File hat vor dem Suffix ein "@" Symbol im namen, also unit@.unit-type.

Von einem Template kann man dann beliebige Instanzen starten. Das Template wird dabei verlinkt, und die Parameter passend ersetzt. Eine numerische ID wird zwischen dem "@" und dem Punkt eingefügt.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]