Ubuntu Manpage: systemd-run - Führt Programme in Units mit flüchtigem Geltungsbereich, Dienste-Units oder durch Pfade,

bezeichnung
übersicht
beschreibung
optionen
exit-status
beispiele
siehe auch
anmerkungen
übersetzung

BEZEICHNUNG

       systemd-run - Führt Programme in Units mit flüchtigem Geltungsbereich, Dienste-Units oder durch Pfade,
       Sockets oder Zeit ausgelöste Dienste-Units aus

ÜBERSICHT

       systemd-run [OPTIONEN…] BEFEHL [ARGS…]

       systemd-run [OPTIONEN…] [PFAD OPTIONEN…] {BEFEHL} [ARGS…]

       systemd-run [OPTIONEN…] [SOCKET OPTIONEN…] {BEFEHL} [ARGS…]

       systemd-run [OPTIONEN…] [ZEITGEBER OPTIONEN…] {BEFEHL} [ARGS…]

BESCHREIBUNG

systemd-run kann zum Erstellen und Starten einer flüchtigen .service- oder .scope-Unit und zur Ausführung
des darin angegebenen BEFEHLs benutzt werden. Es kann auch zum Erstellen und Starten von flüchtigen
.path-, .socket- oder .timer-Units, die beim Ablauf eine .service-Unit aktivieren, verwandt werden.

Falls ein Befehl als flüchtige Dienste-Unit ausgeführt wird, wird er vom Diensteverwalter wie jeder
andere Dienst gestartet und verwaltet, und erscheint daher wie jede andere Unit in der Ausgabe von
systemctl list-units auf. Er wird in einer sauberen und getrennten Ausführungsumgebung ausgeführt, wobei
der Diensteverwalter der Elternprozess ist. In diesem Modus wird systemd-run den Dienst asynchron im
Hintergrund starten und zurückkehren, nachdem der Befehl seine Ausführung begonnen hat (außer --no-block,
--wait, --pipe oder --pty sind angegeben, siehe unten).

Falls ein Befehl als flüchtige Bereichs-Unit ausgeführt wird, wird sie durch systemd-run selbst als
Elternprozess ausgeführt und daher die Ausführungsumgebung des Aufrufenden erben. Allerdings werden die
Prozesse des Befehls durch den Diensteverwalter ähnlich wie bei normalen Diensten verwaltet und werden in
der Ausgabe von systemctl list-units auftauchen. In diesem Fall ist die Ausführung synchron und wird
zurückkehren, wenn der Befehl beendet ist. Dieser Modus wird mit dem Schalter --scope aktiviert (siehe
unten).

Falls ein Befehl mit Pfad-, Socket- oder Timer-Optionen wie --on-calendar= (siehe unten) ausgeführt wird,
wird eine flüchtige Pfad-, Socket- oder Timer-Unit neben der Dienste-Unit für den angegebenen Befehl
erstellt. Nur die flüchtige Pfad-, Socket- oder Timer-Unit wird sofort gestartet, die flüchtige
Dienste-Unit wird durch die Pfad-, Socket- oder Timer-Unit ausgelöst. Falls die Option --unit= angegeben
ist, kann BEFEHL entfallen. In diesem Fall erstellt systemd-run nur eine .path-, .socket- oder
.timer-Unit, die die angegebene Unit auslöst.

Standardmäßig ist die Vorgabe für mit systemd-run erstellte Dienste der simple Typ, siehe die
Beschreibung von Type= in systemd.service(5) für Details. Beachten Sie, dass bei Verwendung dieses Typs
der Diensteverwalter (und daher der Befehl systemd-run) den Dienstestart als erfolgreich betrachten wird,
sobald der fork() für den Hauptdiensteprozess gelang, d.h. bevor der execve() aufgerufen wurde und daher
sogar dann, wenn der angegebene Befehl nicht gestartet werden kann. Prüfen Sie, ob Sie den Dienstetyp
exec verwenden sollten (d.h. --property=Type=exec), um sicherzustellen, dass systemd-run nur erfolgreich
zurückkehrt, falls die angegebene Befehlszeile erfolgreich gestartet wurde.

Nachdem systemd-run den Befehl an den Diensteverwalter übergeben hat, führt der Verwalter die
Variablenexpansion durch. Dies bedeutet, dass Dollar-Zeichen (»$«), die nicht expandiert werden sollen,
als »$$« maskiert werden müssen. Die Expansion kann auch mittels --expand-environment=no deaktiviert
werden.

OPTIONEN

Die folgenden Optionen werden verstanden:

--scope
Erstellt eine flüchtige .scope-Unit statt der standardmäßigen flüchtigen .service-Unit (siehe oben).

Hinzugefügt in Version 206.

--unit=, -u
Verwendet diesen Unit-Namen statt eines automatisch erstellten.

Hinzugefügt in Version 206.

--property=, -p
Setzt auf der erstellten Bereichs- oder Dienste-Unit eine Eigenschaft. Diese Option akzeptiert eine
Zuweisung im gleichen Format wie der Befehl set-property von systemctl(1).

Hinzugefügt in Version 211.

--description=
Stellt eine Beschreibung für die Dienst-, Bereichs-, Pfad, Socket- oder Timer-Unit bereit. Falls
nicht angegeben, wird der Befehl selbst als Beschreibung verwandt. Siehe Description= in
systemd.unit(5).

Hinzugefügt in Version 206.

--slice=
Macht die neue .service- oder .scope-Unit zu einem Teil der angegebenen Scheibe, anstatt von
system.slice (beim Betrieb im Modus --system) oder der Wurzel-Scheibe (beim Betrieb im Modus --user).

Hinzugefügt in Version 206.

--slice-inherit
Macht die neue .service- oder .scope-Unit Teil der Scheibe, in der systemd-run selbst aufgerufen
wurde. Diese Option kann mit --slice= kombiniert werden, dann wird die mittels --slice= angegebene
Scheibe innerhalb der Scheibe abgelegt, in der der Befehl systemd-run aufgerufen wurde.

Beispiel: Betrachten Sie die Situation, dass systemd-run in der Scheibe foo.slice aufgerufen wird und
das Argument --slice= bar lautet. Die Unit wird dann unterhalb von foo-bar.slice eingeordnet.

Hinzugefügt in Version 246.

--expand-environment=LOGISCH
Expandiert Umgebungsvariablen in Befehlsargumenten. Falls aktiviert, werden als »${VARIABLE}«
angegebene Umgebungsvariablen auf die gleiche Art wie mittels ExecStart= in Units festgelegte
Variablen expandiert. Mit --scope wird diese Expansion durch systemd-run selbst durchgeführt und in
anderen Fällen startet der Befehlsverwalter den Befehl. Beachten Sie, dass dies ähnlich aber nicht
identisch zu der Variablenexpansion in bash(1) und anderen Shells ist.

Standardmäßig wird diese Option in allen Fällen aktiviert, außer für --scope, wo sie aus
Rückwärtskompatibilitätsgründen standardmäßig deaktiviert ist. Beachten Sie, dass dies in einer
zukünftigen Veröffentlichung geändert wird, wo es auch dort standardmäßig aktiviert sein wird.

Siehe systemd.service(5) für eine Beschreibung der Variablenexpansion. Die Deaktivierung der
Variablenexpansion ist nützlich, falls der angegebene Befehl ein einzelnes »$« enthält oder enthalten
kann.

Hinzugefügt in Version 254.

-r, --remain-after-exit
Nachdem sich der Diensteprozess beendet hat, wird der Dienst solange bereitgehalten, bis er explizit
gestoppt wird. Dies ist nützlich, um Laufzeitinformationen über den Dienst zu sammeln, nachdem er die
Ausführung beendet hat. Siehe auch RemainAfterExit= in systemd.service(5).

Hinzugefügt in Version 207.

--send-sighup
Wenn die Bereichs- oder Dienste-Unit beendet wird, wird sofort nach SIGTERM ein SIGHUP gesendet. Dies
ist nützlich, um Shells und Shell-artigen Prozessen anzuzeigen, dass die Verbindung gekappt wurde.
Siehe auch SendSIGHUP= in systemd.kill(5).

Hinzugefügt in Version 207.

--service-type=
Setzt den Dienstetyp. Siehe auch Type= in systemd.service(5). Diese Option hat im Zusammenspiel mit
--scope keinen Effekt. Standardmäßig simple.

Hinzugefügt in Version 211.

--uid=, --gid=
Führt den Diensteprozess unter dem angegebenen UNIX-Benutzer und -Gruppe aus. Siehe auch User= und
Group= in systemd.exec(5).

Hinzugefügt in Version 211.

--nice=
Führt den Diensteprozess mit der angegebenen Nice-Stufe aus. Siehe auch Nice= in systemd.exec(5).

Hinzugefügt in Version 211.

--working-directory=
Führt den Diensteprozess mit dem angegebenen Arbeitsverzeichnis aus. Siehe auch WorkingDirectory= in
systemd.exec(5).

Hinzugefügt in Version 240.

--same-dir, -d
Ähnlich wie --working-directory=, verwendet aber das aktuelle Arbeitsverzeichnis des Aufrufenden für
den auszuführenden Dienst.

Hinzugefügt in Version 240.

-E NAME[=WERT], --setenv=NAME[=WERT]
Führt den Diensteprozess mit der angegebenen Umgebungsvariablen gesetzt aus. Dieser Parameter kann
mehr als einmal verwandt werden, um mehrere Variablen zu setzen. Wenn »=« und WERT fehlen, wird der
Wert der Variablen mit dem gleichen Namen in der Programmumgebung verwandt.

Siehe auch Environment= in systemd.exec(5).

Hinzugefügt in Version 211.

--pty, -t
Beim Aufrufen des Befehls verbindet der flüchtige Dienst seine Standardeingabe, -ausgabe und
-fehlerausgabe mittels eines Pseudo-TTY-Gerätes mit dem Terminal, auf dem systemd-run aufgerufen ist.
Dies ermöglicht es, Programme, die interaktive Benutzereingaben-/ausgaben erwarten, wie interaktive
Befehls-Shells, als Dienste auszuführen.

Diese Option führt dazu, dass systemd-run synchron darauf wartet, dass sich der flüchtige Dienst
beendet, ähnlich zur Angabe von --wait. Falls zusammen mit --wait angegeben, wird sich systemd-run
nicht beenden, wenn es manuell vom Pseudo-TTY-Gerät getrennt wird.

Beachten Sie, dass der Befehl shell von machinectl(1) normalerweise eine bessere Alternative zum
Anfordern einer neuen, interaktiven Anmeldesitzung auf dem lokalen Rechner oder einem lokalen
Container ist.

Siehe unten für Details darüber, wie dieser Schalter mit --pipe kombiniert wird.

Hinzugefügt in Version 219.

--pipe, -P
Falls angegeben, werden die Standardeingabe, -ausgabe und -fehlerausgabe von dem flüchtigen Dienst
vom Befehl systemd-run selbst geerbt. Dies ermöglicht es systemd-run, innerhalb von Shell-Pipes
ausgeführt zu werden.

Beachten Sie, dass dieser Modus nicht für interaktive Befehl-Shells oder ähnlichem geeignet ist, da
der Diensteprozess kein TTY-Steuerer wird, wenn er auf einem Terminal ausgeführt wird. Verwenden Sie
in diesem Fall stattdessen --pty.

Falls --pipe und --pty zusammen benutzt werden, wird die geeignetere Option automatisch bestimmt und
verwandt. Insbesondere beim Aufruf, wenn die Standardeingabe, -ausgabe und -fehlerausgabe mit einem
TTY verbunden sind, wird --pty verwandt, andernfalls --pipe.

Diese Option führt dazu, dass systemd-run synchron darauf wartet, dass sich der flüchtige Dienst
beendet, ähnlich zur Angabe von --wait.

Wenn diese Option verwandt wird, werden die ursprünglichen, von systemd-run empfangenen
Dateideskriptoren an den Diensteprozess unverändert weitergegeben. Falls der Dienst mit anderen
Privilegien als systemd-run läuft, kann dies bedeuten, dass der Dienst aufgrund normaler
Dateideskriptorenzugriffsbeschränkungen nicht in der Lage ist, die übergebenen Dateideskriptoren
erneut zu öffnen. Falls der aufgerufene Prozess ein Shell-Skript ist, das das Konstrukt echo "hallo"
>/dev/stderr zum Schreiben von Nachrichten auf der Standardfehlerausgabe verwendet, kann dies zu
Problemen führen, da dies nur funktioniert, falls Stderr erneut geöffnet werden kann. Um diesem
Problem zu begegnen, verwenden Sie stattdessen das Konstrukt echo "hallo" >&2. Dieses ist fast
äquivalent und vermeidet diesen Fallstrick.

Hinzugefügt in Version 235.

--shell, -S
Eine Abkürzung für »--pty --same-dir --wait --collect --service-type=exec $SHELL«, d.h. fordert eine
interaktive Shell im aktuellen Arbeitsverzeichnis an, die im aktuellen Dienstekontext ausgeführt wird
und mit einem einzelnen Schalter erreichbar ist.

Hinzugefügt in Version 240.

--quiet, -q
Unterdrückt zusätzliche informative Ausgaben zur Laufzeit. Dies ist besonders in Kombination mit
--pty nützlich, wo es die anfängliche Nachricht, die erklärt, wie die TTY-Verbindung beendet werden
kann, unterdrückt.

Hinzugefügt in Version 219.

--on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=
Definiert einen monotonen Timer relativ zum Startpunkt zum Starten der angegebenen Befehle. Siehe
OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= und OnUnitInactiveSec= in systemd.timer(5)
für Details. Diese Optionen sind Abkürzungen für --timer-property= mit den relevanten Eigenschaften.
Diese Optionen dürfen nicht mit --scope oder --pty kombiniert werden.

Hinzugefügt in Version 218.

--on-calendar=
Definiert einen Kalenderzeitgeber für das Starten des angegebenen Befehls. Siehe OnCalendar= in
systemd.timer(5). Diese Option ist eine Abkürzungen für --timer-property=OnCalendar=. Diese Option
darf nicht mit --scope oder --pty kombiniert werden.

Hinzugefügt in Version 218.

--on-clock-change, --on-timezone-change
Definiert ein Trigger, basierend auf Systemuhrsprüngen oder Zeitzonenänderungen für das Starten des
angegebenen Befehls. Siehe OnClockChange= und OnTimezoneChange= in systemd.timer(5). Diese Optionen
sind Abkürzungen für --timer-property=OnClockChange=yes und --timer-property=OnTimezoneChange=yes.
Diese Optionen dürfen nicht mit --scope oder --pty kombiniert werden.

Hinzugefügt in Version 242.

--path-property=, --socket-property=, --timer-property=
Setzt auf die zu erstellende Pfad-, Socket- oder Timer-Unit eine Eigenschaft. Diese Option ist
ähnlich --property=, wird aber auf die flüchtige Pfad-, Socket- oder Timer-Unit statt der erstellten
flüchtigen Dienste-Unit angewandt. Diese Option akzeptiert eine Zuweisung im gleichen Format wie der
Befehl set-property von systemctl(1). Diese Option darf nicht mit --scope oder --pty kombiniert
werden.

Hinzugefügt in Version 218.

--no-block
Wartet nicht synchron darauf, dass die Unit-Startaktion beendet wird. Falls diese Option nicht
angegeben ist, wird die Startanfrage für die flüchtige Unit überprüft, in die Warteschlange
eingereiht und systemd-run wird warten, bis das Hochfahren der Unit abgeschlossen ist. Durch Übergabe
dieses Arguments erfolgt nur die Überprüfung und die Einreihung in die Warteschlange. Diese Option
darf nicht mit --wait kombiniert werden.

Hinzugefügt in Version 220.

--wait
Wartet synchron darauf, dass der flüchtige Dienst sich beendet. Falls diese Option angegeben ist,
wird die Startanfrage für die flüchtige Unit überprüft, in die Warteschlange eingereiht und darauf
gewartet. Folgerichtig wird die aufgerufene Unit überwacht und es wird darauf gewartet, dass sie
wieder deaktiviert wird (höchstwahrscheinlich weil der angegebene Befehl abgeschlossen ist). Beim
Beenden wird eine knappe Information über die Laufzeit der Unit angezeigt, einschließlich der
Gesamtlaufzeit (sowie des CPU-Verbrauchs, falls --property=CPUAccounting=1 gesetzt war) und dem
Exit-Code und Status des Hauptprozesses. Diese Ausgabe kann mit --quiet unterdrückt werden. Diese
Option darf nicht mit --no-block, --scope oder den verschiedenen Pfad-, Socket- oder Timer-Optionen
kombiniert werden.

Hinzugefügt in Version 232.

-G, --collect
Entlädt die flüchtigen Unit nach Abschluss, selbst falls sie fehlgeschlagen ist. Normalerweise würden
ohne diese Option alle Units, die liefen und fehlschlugen, im Speicher gehalten, bis der Benutzer
explizit ihren Fehlschlagzustand mit systemctl reset-failed oder einem äquivalenten Befehl
zurücksetzte. Andererseits werden Units, die erfolgreich ausgeführt wurden, sofort entladen. Falls
diese Option eingeschaltet wird, ist die »Müllabfuhr« von Units aggressiver und entlädt Units,
unabhängig davon, ob sie sich erfolgreich beendet haben oder fehlschlugen. Diese Option ist eine
Kurzform für --property=CollectMode=inactive-or-failed, siehe die Erklärung für CollectMode= in
systemd.unit(5) für weitere Informationen.

Hinzugefügt in Version 236.

--ignore-failure
Falls der angegebene Befehl fehlschlägt, wird standardmäßig die aufgerufene Unit als fehlgeschlagen
markiert (allerdings möglicherweise noch entladen, siehe obiges --collect=) und dies wird in den
Protokollen berichtet. Falls dieser Schalter angegeben ist, dann wird dies unterdrückt und jeder
Exit-Status/-Code, der keinen Erfolg anzeigt, wird als Erfolg betrachtet.

Hinzugefügt in Version 256.

--background=FARBE
Ändert die Terminal-Hintergrundfarbe auf die angegebene ANSI-Farbe, solange die Sitzung dauert. Die
angegebene Farbe sollte eine ANSI-X3.64-SGR-Hintergrundfarbe sein, d.h. Zeichenketten wie »40«, »41«,
…, »47«, »48;2;…«, »48;5;…«. Siehe ANSI-Maskier-Code (Wikipedia)[1] zu Details.

Hinzugefügt in Version 256.

--user
Kommuniziert mit dem Diensteverwalter des aufrufenden Benutzers statt mit dem Diensteverwalter des
Systems.

--system
Kommuniziert mit dem Diensteverwalter des Systems. Dies ist die implizite Vorgabe.

-H, --host=
Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen Benutzernamen und
Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden soll. Dem Rechnernamen darf optional
ein Port, auf dem SSH auf Anfragen wartet, getrennt durch »:« und dann ein Container-Name, abgetrennt
durch »/«, folgen, womit direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden
wird. Dies verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in der Ferne zu
kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden. Setzen Sie
IPv6-Adressen in Klammern.

-M, --machine=
Führt die Aktion in einem lokalen Container aus. Geben Sie den Namen des Containers an, zu dem
verbunden werden soll. Optional kann diesem ein Benutzername, abgetrennt durch ein »@«-Zeichen, als
der verbunden werden soll, vorangestellt werden. Falls die besondere Zeichenkette ».host« anstelle
des Container-Names verwandt wird, wird eine Verbindung zu dem lokalen System aufgebaut (das ist
nützlich, um sich zu dem Benutzerbus eines bestimmten Benutzers zu verbinden: »--user
--machine=lennart@.host«. Falls die »@«-Syntax nicht verwandt wird, wird die Verbindung als Benutzer
»root« vorgenommen. Falls die »@«-Syntax verwandt wird, kann entweder die linke oder die rechte Seite
fortgelassen werden (aber nicht beide). In diesem Fall wird der lokale Benutzername und ».host«
angenommen.

-C, --capsule=
Führt die Aktion auf einer Kapsel aus. Geben Sie einen Kapselnamen an, zu dem verbunden werden soll.
Siehe capsule@.service(5) zu Details über Kapseln.

Hinzugefügt in Version 256.

--no-ask-password
Befragt den Benutzer nicht für Authentifizierung für privilegierte Aktionen.

-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.

--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

--json=MODUS
Zeigt die Ausgabe als JSON formatiert. Erwartet entweder »short« (für die kürzest mögliche Ausgabe
ohne unnötigen Leerraum oder Zeilenumbrüche), »pretty« (für eine schönere Version der gleichen
Ausgabe, mit Einzügen und Zeilenumbrüchen) oder »off« (um die JSON-Ausgabe auszuschalten, was die
Vorgabe ist).

Alle Befehlszeilenargumente nach dem ersten Nicht-Optionsargument werden Teil der Befehlszeile des
ausgeführten Prozesses.

EXIT-STATUS

       Im Erfolgsfall wird 0 zurückgeliefert. Falls systemd-run den Dienst nicht starten konnte, wird ein von
       Null verschiedener Wert zurückgeliefert. Falls systemd-run darauf wartet, dass sich der Dienst beendet,
       wird der Rückgabewert vom Dienst weitergeleitet. Im Erfolgsfall wird 0 zurückgeliefert, einschließlich
       aller Fälle, bei denen Systemd davon ausgeht, dass sich der Dienst sauber beendet hat, siehe die
       Besprechung von SuccessExitStatus= in systemd.service(5).

BEISPIELE

Beispiel 1. Protokollieren von Umgebungsvariablen, die von Systemd an Dienste bereitgestellt werden

# systemd-run env
Running as unit: run-19945.service
# journalctl -u run-19945.service
Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64

Beispiel 2. Begrenzen der einem Befehl zur Verfügung stehenden Ressourcen

# systemd-run -p IOWeight=10 updatedb

Dieser Befehl ruft das Werkzeug updatedb(8) auf, senkt aber sein Block-E/A-Gewicht auf 10. Siehe
systemd.resource-control(5) für weitere Informationen über die Verwendung der Eigenschaft IOWeight=.

Beispiel 3. Ausführen eines Befehls zu einer bestimmten Zeit

Der nachfolgende Befehl wird eine Datei nach 30 Sekunden mit »touch« bearbeiten.

# date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
Mon Dec 8 20:44:24 KST 2014
Running as unit: run-71.timer
Will run service as unit: run-71.service
# journalctl -b -u run-71.timer
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
# journalctl -b -u run-71.service
-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.

Beispiel 4. Zugriff auf das TTY erlauben

Der folgende Befehl ruft bash(1) als Dienst auf und übergibt seine Standardeingabe, -ausgabe und
-fehlerausgabe an das aufrufende TTY.

# systemd-run -t --send-sighup bash

Beispiel 5. Screen als ein Benutzerdienst starten

$ systemd-run --scope --user screen
Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.

$ screen -ls
There is a screen on:
492..laptop (Detached)
1 Socket in /var/run/screen/S-fatima.

Dies startet den Prozess screen als ein Kind des Prozesses systemd --user, der in einer Bereichs-Unit von
user@.service gestartet wurde. Es wird statt einer systemd.service(5)-Unit eine systemd.scope(5)-Unit
verwandt, da sich screen beim Abtrennen vom Terminal beenden wird und eine Dienste-Unit beendet würde.
Ausführen von screen in einer Benutzer-Unit hat den Vorteil, dass dies nicht Teil eines Sitzungsbereichs
ist. Falls KillUserProcesses=yes in logind.conf(5) konfiguriert ist (die Vorgabe), wird der
Sitzungsbereich beendet, wenn sich der Benutzer aus dieser Sitzung abmeldet.

Der user@.service wird automatisch gestartet, wenn sich der Benutzer erstmalig anmeldet und bleibt
verfügbar, solange mindestens eine Anmeldesitzung offen ist. Nachdem der Benutzer sich von der letzten
Sitzung abgemeldet hat, werden user@.service und alle darunter befindlichen Dienste beendet. Dieses
Verhalten ist die Vorgabe, wenn »fortbestehend« (engl. »lingering«) nicht für diesen Benutzer aktiviert
ist. Freigabe von fortbestehend bedeutet, dass user@.service automatisch während des Systemstarts
gestartet wird, selbst falls der Benutzer nicht angemeldet ist, und dass der Dienst nicht beendet wird,
wenn sich der Benutzer abmeldet.

Die Freigabe des Fortbestehens erlaubt es Benutzern, Prozesse auszuführen, ohne selbst angemeldet zu
sein, beispielsweise um screen zu erlauben, dauerhaft zu bleiben, nachdem sich der Benutzer abmeldet,
selbst falls der Sitzungsbereich beendet wird. In der Standardkonfiguration können Benutzer das
Fortbestehen selbst aktivieren:

$ loginctl enable-linger

Beispiel 6. Variablenexpansion durch den Verwalter

$ systemd-run -t echo "<${INVOCATION_ID}>" '<${INVOCATION_ID}>'
<> <5d0149bfa2c34b79bccb13074001eb20>

Das erste Argument wird durch die Shell expandiert (doppelte Anführungszeichen), aber das zweite wird
nicht durch die Shell expandiert (einfache Anführungszeichen). echo(1) wird mit ["/usr/bin/echo", "<>",
"<${INVOCATION_ID}>"] als Argumentenfeld aufgerufen und dann erstellt systemd(1) ${INVOCATION_ID} und
ersetzt es in der Befehlszeile. Diese Substitution kann nicht auf der Client-Seite erfolgen, da die
Zielkennung, die für den Dienst gesetzt wird, vor dem Aufruf nicht bekannt ist.

Beispiel 7. Variablenexpansion und Ausgabeumleitung mittels einer Shell

Variablenexpansion durch systemd(1) kann mittels --expand-environment=no deaktiviert werden.

Die Deaktivierung von Variablenexpansion kann nützlich sein, falls der auszuführende Befehl Dollarzeichen
enthält und deren Maskierung unpraktisch wäre. Beispiel bei dem eine Shell verwandt wird:

$ systemd-run --expand-environment=no -t bash \
-c 'echo $SHELL $$ >/dev/stdout'
/bin/bash 12345

Das letzte Argument wird wörtlich an die von der Dienste-Unit gestartete Shell bash(1) übergeben. Die
Shell expandiert »$SHELL« auf den Pfad der Shell und »$$« auf seine Prozessnummer und dann werden diese
Zeichenketten an den eingebauten Befehl echo übergeben und auf der Standardausgabe (die in diesem Fall
mit dem aufrufenden Terminal verbunden ist) ausgegeben.

Beispiel 8. Rückgabewert

$ systemd-run --user --wait true
$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11'
$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 --expand-environment=no \
bash -c 'kill -SIGUSR1 $$'

Diese drei Aufrufe werden erfolgreich sein, d.h. sich mit einem Exit-Code 0 beenden.

SIEHE AUCH

       systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), systemd.scope(5), systemd.slice(5),
       systemd.exec(5), systemd.resource-control(5), systemd.timer(5), systemd-mount(1), machinectl(1), run0(1)

ANMERKUNGEN

        1. ANSI-Maskier-Code (Wikipedia)
           https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters

Ü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
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.