This is really useful for running commands like this:
# systemd-run -i someimage.raw -b systemd.run='"some command line"'
This will now run the command line inside a small Type=oneshot service
and even propagate the exit code of the command back to the parent. And
all that with the full system booted up.
By default this causes the system to shutdown right after the command
completed, but this can be tweaked with systemd.run_success_action= and
systemd.run_failure_action=.
Note that when used in VMs the exit status can of course not be
propagate, as VMs don't really know a concept for that.
This adds SuccessActionExitStatus= and FailureActionExitStatus= that may
be used to configure the exit status to propagate in when
SuccessAction=exit or FailureAction=exit is used.
When not specified let's also propagate the exit status of the main
process we fork off for the unit.
Otherwise we might conflict with the "no-processes-in-inner-cgroup" rule
of cgroupsv2. Consider nspawn starting up and initializing its cgroup
hierarchy with "supervisor/" and "payload/" as subcgroup, with itself
moved into the former and the payload into the latter. Now, if an
ExecStartPre= is run right after it cannot be placed in the main cgroup,
because that is now in inner cgroup with populated children.
Hence, let's run these helpers in another sub-cgroup .control/ below it.
This is somewhat ugly since it weakens the clear separation of
ownership, but given that this is an explicit contract, and double opt-in should be acceptable.
Fixes: #10482
Let's highlight the unit description string in the status updates, to
separate them a bit more the english sentence they are part of, and thus
make the different casing less surprising.
It tests importing and exporting, and a few other machinectl commands.
It currently does not test pulling (i.e. http downloads), but we might
want to add that later on.
Let's use our new path_extract_filename() for extracting the basename
from a path in a safe fashion.
Let's do this for all our three local import calls.
Let's simplify things and drop the logic that /var/lib/machines is setup
as auto-growing btrfs loopback file /var/lib/machines.raw.
THis was done in order to make quota available for machine management,
but quite frankly never really worked properly, as we couldn't grow the
file system in sync with its use properly. Moreover philosophically it's
problematic overriding the admin's choice of file system like this.
Let's hence drop this, and simplify things. Deleting code is a good
feeling.
Now that regular file systems provide project quota we could probably
add per-machine quota support based on that, hence the btrfs quota
argument is not that interesting anymore (though btrfs quota is a bit
more powerful as it allows recursive quota, i.e. that the machine pool
gets an overall quota in addition to per-machine quota).
Let's handle tarball imports nicer that have a single top-level
directory containing the OS tree: let's move everything down during
import, so that the OS tree is ready to use automatically.
Fixes: #2116
Fixes: #2728
This is also supposed to be preparation for doing #10234 eventually,
where a very similar operation is requested: instead of importing a tree
to /var/lib/machines it would need to be imported into
/var/lib/portables/.
This adds two optional functions that may be passed to the various copy
functions. One is invoked whenever we start copying a new file object,
the other while we copy file payload in each loop iteration.
When the caller passes one or both they can get notifications about copy
progress, for example to log where things are.
We invoke this usually on a temporary path before renaming it into
place. This means the log message is quite suprising as it mentions a
weird path with random characters in it. Hence, let's downgrade the
message in order not to confuse the user.
Lennart Poettering