Provided by: manpages-de_2.15-1build1_all bug

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 festgelegten 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 taucht 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 oder
       --wait sind festgelegt, 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 Zeitgeberoptionen wie --on-calendar= (siehe
       unten) ausgeführt wird, wird eine flüchtige Pfad-, Socket- oder Zeitgeber-Unit neben der
       Dienste-Unit für den festgelegten Befehl erstellt. Nur die flüchtige Pfad-, Socket- oder
       Zeitgeber-Unit wird sofort gestartet, die flüchtige Dienste-Unit wird durch die Pfad-,
       Socket- oder Zeitgeber-Unit ausgelöst. Falls die Option --unit= festgelegt ist, kann
       BEFEHL entfallen. In diesem Fall erstellt systemd-run nur eine .path-, .socket- oder
       .timer-Unit, die die festgelegte 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 festgelegte 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 festgelegte Befehlszeile erfolgreich gestartet
       wurde.

OPTIONEN

       Die folgenden Optionen werden verstanden:

       --no-ask-password
           Den Benutzer nicht für Authentifizierung für privilegierte Aktionen befragen.

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

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

       --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).

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

       --slice=
           Macht die neue .service- oder .scope-Unit zu einem Teil der festgelegten Scheibe,
           anstatt von system.slice.

       -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).

       --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).

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

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

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

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

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

       -E NAME=WERT, --setenv=NAME=WERT
           Führt den Diensteprozess mit den festgelegten Umgebungsvariablen aus. Siehe auch
           Environment= in systemd.exec(5).

       --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.

           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
           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.

           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
           Eine Abkürzung für »--pty --same-dir --wait --collect --service-type=exec $SHELL«,
           d.h. erbittet eine interaktive Shell im aktuellen Arbeitsverzeichnis, die im aktuellen
           Dienstekontext ausgeführt wird und mit einem einzelnen Schalter erreichbar ist.

       --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.

       --on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=
           Definiert einen monotonen Zeitgeber relativ zum Startpunkt zum Starten der
           festgelegten 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.

       --on-calendar=
           Definiert einen Kalenderzeitgeber für das Starten des festgelegten 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.

       --path-property=, --socket-property=, --timer-property=
           Setzt auf die zu erstellende Pfad-, Socket- oder Zeitgeber-Unit eine Eigenschaft.
           Diese Option ist ähnlich --property=, wird aber auf die flüchtige Pfad-, Socket- oder
           Zeitgeber-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.

       --no-block
           Nicht synchron darauf warten, dass die Unit-Startaktion beendet wird. Falls diese
           Option nicht festgelegt 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.

       --wait
           Synchron darauf warten, dass der flüchtige Dienst sich beendet. Falls diese Option
           festgelegt 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 festgelegte 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 Zeitgeberoptionen kombiniert werden.

       -G, --collect
           Entladen der 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.

       --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 auf dem festgelegten Host angehängt werden, 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.
           Stellen 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.

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

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

       Alle Befehlszeilenargumente nach dem ersten Nicht-Optionsargument werden Teil der
       Befehlszeile des ausgeführten Prozesses. Falls ein Befehl als Dienste-Unit ausgeführt
       wird, muss das erste Argument ein absoluter Programmpfad sein.

EXIT-STATUS

       Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.

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 BlockIOWeight=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 BlockIOWeight=.

       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 Dez  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
           -- Logs begin at Fri 2014-12-05 19:09:21 KST, end 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
           -- Logs begin at Fri 2014-12-05 19:09:21 KST, end 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 /bin/bash als Dienst auf und übergibt seine Standardeingabe,
       -ausgabe und -fehlerausgabe an das aufrufende TTY.

           # systemd-run -t --send-sighup /bin/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

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 <debian-l10n-german@lists.debian.org>.