Before:
====
$ systemctl edit network.target
Failed to create directories for "/etc/systemd/system/network.target.d/override.conf": No such file or directory
====
After:
====
$ systemctl edit network.target
Failed to create directories for "/etc/systemd/system/network.target.d/override.conf": Permission denied
====
Fixes#26652.
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.
This adds a test for checking we can safely order boot IDs via the
timestamp of their most recent known entry. It takes a set of journal
files (supplied by a user) and that are partially corrupted, and ensures
we get a clear, defined order of boot IDs out of it.
With this we should be able to determine on systems without
battery-backed RTC even during early boot whether a boot is supposed to
be earlier than another.
Fixes: #662
This is useful to later order boot IDs by time, addressing #662.
Basically, this determines the most recently written for each boot ID
from all currently open journal files. This is then stored in a hash
table (which maps the boot ID to a prioq of journal files, ordered by
their timestamp).
Why is this useful? If systems lack a battery-buffered RTC they will
initially have a system clock basically starting at zero. Later they
might acquire an NTP fix, or at least roughly monotonic time via a
stored timestamp. Thus, log entries written early during boot tend to be
badly timestamped, and those written most recently are likely to have
most accurate timestamps. Thus, if we track the newest entry for each
boot ID we likely can order the boot ID via their timestamps.
This commit only add the logic to maintain the hash table/prioq. It
doesn't actually make use of this information for ordering yet. A later
patch adds that.
This way we can quickly find the most recent entry, without searching or
traversing entry array chains.
This is relevant later, as it it allows us to quickly determine the most
recent timestamps of each journal file, in a roughly atomic way.
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.
Yu Watanabe
Lennart Poettering
Luca Boccassi
Michal Koutný
msizanoen1
Frantisek Sumsal
dependabot[bot]