table of contents
- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.25.0-1
| SYSTEMD-RUN(1) | systemd-run | SYSTEMD-RUN(1) |
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:
--no-ask-password
--scope
--unit=, -u
--property=, -p
--description=
--slice=
--slice-inherit
Eine ererbte Scheibe befindet sich innerhalb der Scheibe systemd-run. Beispiel: Falls die Scheibe systemd-run »foo.slice« und das Argument --slice= »bar« ist, dann wird die Unit unterhalb von »foo-bar.slice« eingeordnet.
--expand-environment=LOGISCH
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.
-r, --remain-after-exit
--send-sighup
--service-type=
--uid=, --gid=
--nice=
--working-directory=
--same-dir, -d
-E NAME[=WERT], --setenv=NAME[=WERT]
Siehe auch Environment= in systemd.exec(5).
--pty, -t
This option will result in systemd-run synchronously waiting for the transient service to terminate, similar to specifying --wait. If specified along with --wait, systemd-run won't exit when manually disconnecting from the pseudo TTY device.
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.
--pipe, -P
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.
This option will result in systemd-run synchronously waiting for the transient service to terminate, similar to specifying --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.
--shell, -S
--quiet, -q
--on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=
--on-calendar=
--on-clock-change, --on-timezone-change
--path-property=, --socket-property=, --timer-property=
--no-block
--wait
-G, --collect
--user
--system
-H, --host=
-M, --machine=
-h, --help
--version
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 ü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)
Ü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 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.
| systemd 254 |