RootDirectory= but via a open_tree() file descriptor. This allows
setting up the execution environment for a service by the client in
a mount namespace and then starting a transient unit in that execution
environment using the new property.
We also add --root-directory= and --same-root-dir= to systemd-run to
have it run services within the given root directory. As systemd-run
might be invoked from a different mount namespace than what systemd is
running in, systemd-run opens the given path with open_tree() and then
sends it to systemd using the new RootDirectoryFileDescriptor= property.
When services start up they might query for passwords, or issue polkit
requests. Hence it makese sense to run the password query agent and
polkit agent from systemd-run. We already ran the polkit agent, this
also ensures we run the password query agent.
There's one tweak to the story though: running the agents and the pty
forwarder concurrently is messy, since they both try to read from stdin
(one potentially, the other definitely). Hence, let's time the agents
properly: invoke them when we initialize, but stop them once the start
job for the unit we are supposed to run is complete, and only then run
the pty forwarder.
With this in place, the following series of commands starts to work
really nicely (which previously deadlocked):
# homectl create foobar
# run0 -u foobar
What happens in the background in run0 is this: a new session is invoked
for "foobar", which pulls in the user@.service instance for the user.
That user@.service instance will need to unlock the homedir first. Since
8af1b296cb this will happen via the askpw
logic. With this commit here this prompt will now be shown by run0. Once
the password is entered the directory is unlocked and the real session
begins. Nice!
This new behaviour is conditioned behind --pty-late (distinct from the
existing --pty switches). For systemd-run we will never enable this mode
by default, for compat with command lines that use ExecStartPre=
(because we won't process the pty anymore during that command) For
run0 however this changes the default to --pty-late (unless
--no-ask-password is specified). This reflects the fact that run0 is
more of an interctive tool and unlikely to be used in more complex
service start-up situations with ExecStartPre= and suchlike.
This also merges JobDoneContext into RunContext, since it doesn't really
make sense to have two contexts around to communicate between outer
stack frame and event handlers. Let's just have one, and pass it around
to all handlers the same way. In particular as we should delay exit only
until both the unit's job is complete *and* in case of --wait the unit
is exited, one of the two should not suffice.
systemctl has a --job-mode= argument, and adding the same argument to
systemd-run is useful for starting transient scopes with dependencies.
For example, if a transient scope BindsTo a service that is stopping,
specifying --job-mode=replace will wait for the service to stop before
starting it again, while the default job mode of "fail" will cause the
systemd-run invocation to fail.
In the troff output, this doesn't seem to make any difference. But in the
html output, the whitespace is sometimes preserved, creating an additional
gap before the following content. Drop it everywhere to avoid this.
Naming is always a matter of preference, and the old name would certainly work,
but I think the new one has the following advantages:
- A verb is better than a noun.
- The name more similar to "the competition", i.e. 'sudo', 'pkexec', 'runas',
'doas', which generally include an action verb.
- The connection between 'systemd-run' and 'run0' is more obvious.
There has been no release yet with the old name, so we can rename without
caring for backwards compatibility.
This adds a new --background= switch that allows specifiying a
background color for the terminal while the tool runs.
It also teaches the tool when invoked as uid0 to tint the terminal in a
reddish hue when operating as root, and in a yellowish hue when
operating as any other user.
This should highlight nicely when the user is operating with elevated
privileges, or changed privileges.
This turns "systemd-run" into a multi-call binary. When invoked under
the name "uid0", then it behaves a bit more like traditional "sudo".
This mostly means defaults appropriuate for that, for example a PAM
stack, interactivity and more.
Fixes: #29199
As I noticed a lot of missing information when trying to implement checking
for missing info. I reimplemented the version information script to be more
robust, and here is the result.
Follow up to ec07c3c80b
This tries to add information about when each option was added. It goes
back to version 183.
The version info is included from a separate file to allow generating it,
which would allow more control on the formatting of the final output.
The intention was to have this option enabled by default everywhere,
but unfortunately at least one case was found where it breaks
compatibility of a program using systemd-run --scopes and expecting
variables not to be expanded:
https://sources.debian.org/src/pbuilder/0.231/pbuilder-checkparams/#L400
Example run:
systemd-run --quiet --scope --description=pbuilder_build_xfce4-notes-plugin_1.10.0-1.dsc '--slice=system-pbuilder-build-xfce4\x2dnotes\x2dplugin_1.10.0\x2d1-449932.slice' chroot /var/cache/pbuilder/build/449932 dpkg-query -W '--showformat=${Version}' apt
Restore backward compatibility and make the option disabled by default
when --scope is used, and enabled by default for other types.
In case --expand-environment is not specified and a '$' character is
detected, print a warning to nudge users toward specifying the
parameter as needed. In the future we can then flip the default.
Follow-up for 2ed7a221fa
This makes syntax be the same for commands which are started by the manager and
those which are spawned directly (when --scope is used).
Before:
$ systemd-run -q -t echo '$TERM'
xterm-256color
$ systemd-run -q --scope echo '$TERM'
$TERM
Now:
$ systemd-run -q --scope echo '$TERM'
xterm-256color
Previous behaviour can be restored via --expand-environment=no:
$ systemd-run -q --scope --expand-environment=no echo '$TERM'
$TERM
Fixes#22948.
At some level, this is a compat break. Fortunately --scope is not very widely
used, so I think we can get away with this. Having different syntax depending
on whether --scope was used or not was bad UX.
A NEWS entry will be required.
This uses StartExecEx to get the equivalent of ExecStart=:. StartExecEx was
added in b3d593673c, so this will not work with
older systemds.
A hint is emitted if we get an error indicating lack of support. PID1 returns
SD_BUS_ERROR_PROPERTY_READ_ONLY, but I'm checking for
SD_BUS_ERROR_UNKNOWN_PROPERTY too for safety.
(The one case that is left unchanged is '< <(subcommand)'.)
This way, the style with no gap was already dominant. This way, the reader
immediately knows that ' < ' is a comparison operator and ' << ' is a shift.
In a few cases, replace custom EOF replacement by just EOF. There is no point
in using someting like "_EOL" unless "EOF" appears in the text.
This comes up occasionally with new users. The phrase "Logs begin ..." is
ambiguous because it can be taken to mean the logs being displayed or all logs
(the intended meaning). Let's rephrase this as "Journal begins ..." to make
this clearer.
Fixes#13756. We were returning things that didn't make much sense:
we would always use the exit_code value as the exit code. But it sometimes
contains a exit code from the process, and sometimes the number of a signal
that was used to kill the process. We would also ignore SuccessExitStatus=
and in general whether systemd thinks the service exited successfully
(hence the issue in #13756, where systemd would return success/SIGTERM,
but we'd just look at the SIGTERM part.)
If we are doing --wait, let's always propagate the exit code/status from
the child.
While at it, make the documentation useful.
