ubuntuusers.de

User Units

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

systemd User Units unterscheiden sich von "normalen" Units nur in so fern, dass die Units nicht beim Systemstart mit gestartet werden, sondern erst wenn der Nutzer, für den die Unit aktiviert ist, sich auf dem System anmeldet. Dabei spielt es keine Rolle, ob die Anmeldung lokal direkt am Rechner erfolgt oder von außerhalb, z.B. über SSH. Die Unit wird automatisch wieder beendet, wenn der Nutzer vom System vollständig abgemeldet ist.

Ein Beispiel für eine User Unit - welche auch standardmäßig bei Ubuntu aktiviert ist - ist das Löschen aller temporärer Dateien, die vom System angelegt werden, so lange ein Nutzer angemeldet ist.

Benutzung

User Units funktionieren grundsätzlich genau so wie systemweite Units, auch die entsprechenden Unit-Dateien sind identisch aufgebaut. Details hierzu sind im Wikiartikel systemd/Units zu finden.

User Units laufen standardmäßig mit den Rechten des Nutzer, für den die Unit gestartet wird.

Sichtbarkeit für andere Nutzer

Auch, wenn eine User Unit beim Anmelden für einen Nutzer gestartet wird, läuft die Unit nicht exklusiv oder gekapselt für diesen Nutzer. Startet man z.B. den im Unit Howto genutzten Server als User Unit, können auch alle anderen am System angemeldeten Nutzer auf den Server zugreifen.

Programme mit grafischer Oberfläche Starten

systemd ist grundsätzlich dafür gemacht, Dienste und Prozesse im Hintergrund zu starten. Es ist nicht dafür gemacht, Programme mit grafischer Oberfläche im Vordergrund zu starten. Technisch ist dies zwar über ein paar "Umwege" möglich, aber der bessere Weg zum Starten von grafischen Programmen nach dem Anmelden im System sind nach wie vor die Autostart-Mechanismen der verschiedenen Desktopumgebungen.

Speicherorte

Dateien für User Units sind unter Ubuntu an vier Stellen im Dateisystem abgelegt:

  • /usr/lib/systemd/user: Hier liegen alle vorinstallierten Dateien von benutzerbezogenen Units.

  • /etc/systemd/user: Hier liegen als Units, welche selber angelegt wurden und für jeden Nutzer des Systems aktiviert werden können. Für das Anlegen oder Editieren von Units in diesem Verzeichnis sind Root-Rechte notwendig.[2]

  • ~/.local/share/systemd/user: Hier liegen Units von Paketen, die lokal nur für den Nutzer installiert sind.

  • ~/.config/systemd/user: Hier liegen alle Dateien von benutzerbezogenen Units, welche durch den jeweiligen Nutzer selbst angelegt oder editiert werden. Änderungen sind nur für Units in /usr/lib/systemd/user möglich, nicht für systemweite Units. Da die entsprechenden Dateien unterhalb des Homeverzeichnisses des Benutzers liegen, sind hierfür keine Root-Rechte erforderlich.

Die Priorität von Units im Homeverzeichnis ist höher als die in den systemweiten Verzeichnissen, d.h. gibt es eine gleichnamige Unit z.B. in /etc/systemd/user und ~/.config/systemd/user, dann hat die in letzterem Verzeichnis die höhere Priorität und wird geladen.

eigene User Units anlegen

Das Anlegen eigener User Units erfolgt genau so wie im Units-Artikel beschrieben, es gelten die gleiche Sektionen und Direktiven in den verschiedenen Units. In der [Install]-Sektion der Unit wird üblicherweise (aber nicht zwingender Weise) WantedBy=default.target angegeben, da alle anderen, früheren Targets, in der Regel bereits erreicht sind, wenn man sich als Nutzer anmelden kann.

Das Aktivieren, Deaktivieren etc. von User Units erfolgt ebenfalls mittels systemctl, aber man benötigt keine Root-Rechte, fügt dafür aber die Option --user hinzu. Der folgende Befehl

systemctl --user enable meine_unit.service 

würde z.B. die Service-Unit meine_unit als User Unit aktivieren.

Interaktion mit System Units

In der Standardkonfiguration werden User Units erst gestartet, wenn alle System Units bereits laufen, weil sich der Nutzer erst anmelden kann, wenn das System komplett gestartet ist. Von daher machen Direktiven wie After=... auf bestimmte Units oder Targets, die beim Starten des Systems abgearbeitet werden, in der Regel keinen Sinn.

Des Weiteren werden beim Herunterfahren des Systems erst die User Units beendet, bevor die System Units abgearbeitet werden bzw. Targets des Herunterfahrens erreicht werden. Von daher machen auch Direktiven auf solche Targets in User Units in der Regel keinen Sinn.

Man kann das Verhalten von User Units aber mit enable-linger oder die Anpassung des Werts KillUserProcesses=...in der Konfigurationsdatei logind.conf 🇬🇧 ändern.

Umgebungsvariablen

Auch, wenn User Units erst beim Anmelden ausgeführt werden, liest systemd nicht die Konfigurationsdateien des Nutzers wie z.B. .bashrc ein. Damit haben die gestarteten Prozesse auch keinen Zugriff auf die Umgebungsvariablen des Nutzer. Werden Umgebungsvariablen benötigt, so sind diese wie im Artikel systemd/Umgebungsvariable beschrieben zu setzen.

Logs zu User Units

User Units schreiben standardmäßig ihre Ausgaben / Logs ebenfalls über journald: in den systemweiten Log. Um die Logs von den eigenen User Units gezielt abzufragen, ruft man journalctl ebenfalls mit der Option --user auf:

journalctl --user 

Ansonsten gelten die gleichen Optionen wie im journalctl Wikiartikel beschrieben.

User Units ohne Anmeldung starten

Besteht die Notwendigkeit, dass für einen Nutzer User Units beim Systemstart - also ohne Anmeldung des Nutzers am System - gestartet werden bzw. User Units auch nach dem Abmelden weiterlaufen statt beendet werden, ist dies über systemd loginctl 🇬🇧 möglich.

Der folgende Befehl aktiviert dieses Verhalten für den Nutzer NUTZER[1][2]

sudo loginctl enable-linger NUTZER 

Deaktiviert wird es über:

sudo loginctl disable-linger NUTZER 

Diese Revision wurde am 30. April 2020 02:34 von Atalanttore erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: systemd, System