@brauner noticed that in invoked containers the root directory is set to
still receive mounts from the host. We should disable that, and
guarantee we live in our own world, because that's what an
(nspawn-style) container *is* after all: a whole new world.
This hence mounts the container subtree to MS_PRIVATE after getting the
root dir in place. Note that this will later be set to MS_SHARED again.
The MS_PRIVATE disconnects mounts from the host, the MS_SHARED then
establishes a new peer group for mount propagation events, so that
payload service managers (such as systemd) can take benefit of
propagation further down the tree.
When mkosi is run from git-worktree(1), the .git is not a repository
directory but a textfile pointing to the real git dir
(e.g. /home/user/systemd/.git/worktrees/systemd-worktree). This git dir
is not bind mounted into build environment and it fails with:
> fatal: not a git repository: /home/user/systemd/.git/worktrees/systemd-worktree
> test/meson.build:190:16: ERROR: Command `/usr/bin/env -u GIT_WORK_TREE /usr/bin/git --git-dir=/root/src/.git ls-files ':/test/dmidecode-dumps/*.bin'` failed with status 128.
There is already a fallback to use shell globbing instead of ls-files,
use it with git worktrees as well.
This ensures that shell string escape operations will not produce output
with invalid UTF-8 from the input by escaping invalid UTF-8 data as if
they were single byte characters.
systemd-hwdb update is an expensive operation by itself, and when
running with sanitizers and in a VM without acceleration this cost is
exacerbated even further, making the test run for a very long time.
For example, in the daily CentOS CI ppc64le job with ASan+UBSan one
systemd-hwdb update takes more than 7 minutes; in the regular Arch job
with KVM it takes over 2 minutes.
Since the hwdb update is also tested in other places (like
TEST-01-BASIC and the test-hwdb meson test), let's skip it if we detect
we run with sanitizers and with plain QEMU.
Since quite a while the propagation from the DDI arch into the
personality() wasn't hooked up anymore. Let's fix that: when the DDI has
a determined arch, automatically propagate this into the personality.
Let's make things systematic: the per-user and the per-system manager
should manage their own memory pressure, as they are, well, managers of
things.
This is particularly relevant and the per-user service manager should
watch its own "init.scope" subcgroup, instead of the main service unit
cgroup, and hence $MEMORY_PRESSURE_WATCH as set by the per-system
service manager would simply be wrong.
And also: by default, for the systemd-user service and for local
sessions (i.e. those assigned to a seat): let's imply CAP_WAKE_SYSTEM
for them by default. Yes, let's pass one specific capability by default to local
unprivileged users.
The capability services exactly once purpose: to allow system wake-up
from suspend via alarm clocks, hence is relatively limited in focus. By
adding this tools such as GNOME's Alarm Clock app can simply allocate a
CLOCK_REALTIME_ALARM (or ask systemd --user to do this) timer and it
will wake up the system as necessary.
Note that systemd --user will not pass the ambient caps on by default,
so even with this change, individual services need to use
AmbientCapabilities= to pass this on to the individual programs.
Fixes: #17564#21382
"passwd" and "pscap" are extremely useful to debug basic OS behaviour,
and tiny. So let's add them to our default development images, just to
save us some headaches.
Lennart Poettering
Luca Boccassi
Michal Koutný
msizanoen1
Frantisek Sumsal
dependabot[bot]
Antonio Alvarez Feijoo
Jan Janssen