Since commit 8d3e4ac7cd ("scope: refuse
activation of scopes if no PIDs to add are left") all "systemd-run --scope
--user" calls fail because cgroup attachments delegated to the system instance
are not counted towards successful additions. Fix this by incrementing the
return value in case unit_attach_pid_to_cgroup_via_bus() succeeds, similar to
what happens when cg_attach() succeeds directly.
Note that this can *not* distinguish the case when
unit_attach_pid_to_cgroup_via_bus() has been run successfully, but all
processes to attach are gone in the meantime, unlike the checks that commit
8d3e4ac7cd adds for the system instance. This is
because even though unit_attach_pid_to_cgroup_via_bus() leads to an internal
unit_attach_pids_to_cgroup() call, the return value over D-Bus does not include
the number of successfully attached processes and is always NULL on success.
Fixes: #21297
And while we are at it, make 'ssh-authorized-keys' verb properly
documented. Given that OpenSSH documents the interface in its man page
it's fine to just document our implementation of it too.
Moving all of the gnu-efi detection into src/boot/efi/meson.build makes
more sense than having it partially split.
And thanks to subdir_done() we can simplify the code a lot.
Fixes: #21258
The discovery partitions spec so far suggested we should define
arch-specific partition type uuids only for archs that have EFI. Let's
change that and invite people to define them for any arch. Why? Even if
GPT is defined as part of the UEFI spec it's quite useful independently
of it, too. Specifically, our image dissection logic makes use of it,
i.e. systemd-nspawn, systemd-gpt-auto-generator, systemd-repart,
RootImage=, portable services, and so on. None of these tools are
related to UEFI in any way.
Hence, let's open this up.
Defines a "UNIT_DEPENDENCY_SLICE_PROPERTY" UnitDependencyMask type that
is used when adding slices to the dependencies hashmap. This type is
used to remove slice dependencies when they get overridden by new ones.
Fixes#20182
Our goal here (as in the previous commits) is to ensure that a settings
file loaded in --settings=override mode is truly a NOP. Previously this
was not the case as we'd drop CAP_NET_ADMIN from the caps if the
settings file didn't enable networking.
With this change we'll drop it only if explicitly turned off in the
settings file, and otherwise let the built-in defaults and cmdline
params reign supreme as documented.
Fixes: #20055
Let's only pick this up from the settings if actually set.
As in the previous commit this makes sure that an empty settings file in
--settings=override mode is really a NOP.
Let's turn these three fields into tristates, so that we can distinguish
whether they are not configured at all from explicitly turned off.
Let#s then use this to ensure that we only copy the settings fields into
our execution environment if they are actually configured.
We already do this for some of the boolean settings, this adds it for
the missing ones.
The goal here is to ensure that an empty settings file used in
--settings=override mode (i.e. the default mode used in the
systemd-nspawn@.service unit) is truly a NOP.
The new helper returns whether the settings file had *any* networking
setting configured at all. We already have a similar helper
settings_private_network() which returns a similar result. The
difference is that the new helper will return true when the private
network was explicitly turned off, while the old one will only return
true if configured and enabled.
We'll reuse the helper a 2nd time later on, but even without it it makes
things a bit more readable.