diff options
| author | Lennart Poettering <lennart@poettering.net> | 2016-12-24 01:08:15 +0100 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2016-12-27 18:32:45 +0100 |
| commit | 7f129a1f7c934123061aa26029cff1784805f878 (patch) | |
| tree | 08e64b18e474ded3f327c8dc877176ff2f063c0b /man/systemd-run.xml | |
| parent | 27e2e3231fc1edbbaa9f73be363900701ab4598d (diff) | |
| download | systemd-7f129a1f7c934123061aa26029cff1784805f878.tar.gz | |
man: document that "systemd-run -M" propagates exit codes, and "machinectl shell" does not
This adds a brief explanation, suggesting the use of "systemd-run -M" to
acquire exit status/code information for the invoked process.
My original plan was to propagate the exit code/status in "machinectl
shell" too, but this would mean we'd have to actively watch the shell's
runtime status, and thus would need full, highly privileged and
continious access to the container's system manager, the way
"systemd-run" does it. This would be quite a departure from the
simplistic, low-priviliged OpenShell() bus call implementation of the
current code, that really just acquires a PTY device with a shell
connected.
Moreover it would blur the lines between the two commands even further,
which I think is not desirable. Hence, from now on:
"machinectl shell" is the full-session, interactive shell for human
users
"systemd-run -M …" is the low-level tool, that supports
on-interactive mode, and is more configurable and suitable for
streaming.
Fixes: #4215
Diffstat (limited to 'man/systemd-run.xml')
| -rw-r--r-- | man/systemd-run.xml | 7 |
1 files changed, 6 insertions, 1 deletions
diff --git a/man/systemd-run.xml b/man/systemd-run.xml index 2ad8cb0835..8d881f15d6 100644 --- a/man/systemd-run.xml +++ b/man/systemd-run.xml @@ -221,7 +221,12 @@ <listitem><para>When invoking the command, the transient service connects its standard input and output to the terminal <command>systemd-run</command> is invoked on, via a pseudo TTY device. This allows running binaries - that expect interactive user input as services, such as interactive command shells.</para></listitem> + that expect interactive user input as services, such as interactive command shells.</para> + + <para>Note that + <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s + <command>shell</command> command is usually a better alternative for requesting a new, interactive login + session on the local host or a local container.</para></listitem> </varlistentry> <varlistentry> |