Luca Boccassi [Mon, 1 Jun 2026 11:15:52 +0000 (12:15 +0100)]
Translations update from Fedora Weblate (#42417)
Translations update from [Fedora
Weblate](https://translate.fedoraproject.org) for
[systemd/main](https://translate.fedoraproject.org/projects/systemd/main/).
manager: if called with compat telinit interface, tell users to update
In https://bugzilla.redhat.com/show_bug.cgi?id=2479961 a user
reported that they are confused that 'init 6' and such commands
do not work anymore. We removed support for the whole interface,
but it's likely that such commands persist in various scripts
and finger memories. Let's give a helpful hint that this inteface
is gone and what to use instead.
We shouldn't say that that they boot into "a … legacy target", because
they boot into the standard targets. Those names are just aliases now.
(And also the user is not required to know what SysV even is, so it
shouldn't be used in the main explanation.)
Luca Boccassi [Mon, 1 Jun 2026 09:09:43 +0000 (10:09 +0100)]
docs: specifically mention that braces in if blocks do not need to be symmetric
The claude bot keeps getting this wrong again and again:
Claude: nit: systemd coding style requires braces on both branches of
an if/else when one branch uses them. Here the if branch
is a single statement without braces but the else branch
uses braces
Specifically mention this is not the case in the coding style doc
to hopefully make it stop hallucinating this rule
Luca Boccassi [Sun, 31 May 2026 16:38:40 +0000 (17:38 +0100)]
test: make TEST-60-MOUNT-RATELIMIT more robust
TEST-60-MOUNT-RATELIMIT sometimes fails as it cannot see the 'left rate limit'
message in the journal. Tests relying on specific log messages are often flaky,
as the journal is lossy.
Change the test case to check for the desired outcome instead, as that also
catches regressions, without being over reliant on the journal.
Luca Boccassi [Sun, 31 May 2026 11:44:14 +0000 (12:44 +0100)]
journalctl: don't assert on MESSAGE field without "MESSAGE=" prefix
sd_journal_get_data() can return a MESSAGE data object whose payload does
not start with "MESSAGE=", e.g. when the journal file is corrupted. Instead
of aborting the whole process, log and skip over such an entry like we do for
other bad/missing fields.
Luca Boccassi [Sun, 31 May 2026 10:55:15 +0000 (11:55 +0100)]
Translations update from Fedora Weblate (#42403)
Translations update from [Fedora
Weblate](https://translate.fedoraproject.org) for
[systemd/main](https://translate.fedoraproject.org/projects/systemd/main/).
Currently translated at 100.0% (285 of 285 strings)
Co-authored-by: Fco. Javier F. Serrador <fserrador@gmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/es/
Translation: systemd/main
tmpfiles: exclude x11 lock files from time-based cleanup
We need a removal rule for systems where /tmp is not on tmpfs,
so that if they crash, stale sockets will be removed during boot.
OTOH, at runtime, those lock files must never be removed.
But since the 'r!' rule uses '!', it only applies during boot. With
the rule inactive, the usual time-based cleanup for /tmp/ was also
applied to those files, causing them to be removed after 10 days.
tmpfiles: remove boot-only restriction from x11 directory rules
4a1f92c704aad80e9fde3f3d1678a5e5e944ae47 added '!' through confusion:
the goal was probably to exclude those directories from cleanup at
runtime. But as discussed below, that exclusion is not needed. In fact,
we want the rule to be active during runtime, so that if the directory
were removed or wasn't created earlier for whatever reason, it'd be
created during one of those later runs too. This just makes the system
more robust.
Those directories are used for sockets, and tmpfiles will not remove
live sockets. So it is fine to run the cleanup on those directories,
it doesn't have any effect in normal circumstances. The only case where
the cleanup would matter would be if the service was running, crashed
without removing the socket, and the system would remain up for more
than 10 days after that. This is not a particularly likely scenario, but
OTOH, we can imaging that somebody tried to run Xorg, it didn't work,
and they switched to Wayland. Or their DE crashes every once in a while,
leaving some state behind. Keeping the cleanup in place seems OK, it
makes the system slightly more robust in fringe scenarios.
In fact, this cleanup will work better if we reduce the delay from
10 days to something small. systemd-tmpfiles-clean.timer runs once
per day, so the cleanup will not be very fast anyway. So use '1h' as
an arbitrary small value. (I think '0' would be risky, because it's
possible for the socket to be set up through a script where it's
created first and the service is connected to it, so it is momentarily
"not live". I think people used to do this. Not sure if that happens
anymore, but let's be safe.)
Luca Boccassi [Fri, 29 May 2026 12:42:24 +0000 (13:42 +0100)]
ci: add build/unit-test coverage for armv7
arm64 hosts support running armv7 (armhf) binaries, so we can
cross compile and run the unit tests without performance issues.
armv7 (armhf) is a primary architecture on Ubuntu, so build
regressions block new version updates, and adding coverage
helps to avoid introducing regressions.
Luca Boccassi [Fri, 29 May 2026 11:37:31 +0000 (12:37 +0100)]
hwdb: reject overlong fnmatch key instead of passing NULL to fnmatch()
When the accumulated trie key exceeds the fixed-size line buffer,
linebuf_get() returns NULL. trie_fnmatch_f() passed that NULL straight
into fnmatch() as the pattern, causing a SIGSEGV on a crafted hwdb.bin
(reachable now that recursion is capped rather than overflowing the
stack first). Treat the NULL like the other corruption checks and
return -EBADMSG.
Daan De Meyer [Fri, 29 May 2026 07:16:33 +0000 (07:16 +0000)]
ssh-proxy: Default to root user
When ssh-ing into a VM, you generally do not want to log
in as your user from the host. Let's default to the root
user unless a user is explicitly specified.
Daan De Meyer [Thu, 28 May 2026 09:26:05 +0000 (09:26 +0000)]
ssh-generator: Make sure sshd can always read the authorized keys file
sshd reads AuthorizedKeysFile after dropping to the authenticating user's UID, so the
0400 credential file under %d/ is unreadable for non-root users. Materialize a 0444
copy in a RuntimeDirectory so the ephemeral key works for any user. */
Luca Boccassi [Thu, 28 May 2026 18:24:36 +0000 (19:24 +0100)]
oom: use cgroup.kill if available
The log message is informational only, same as the count of killed
processes, so we can safely use cgroup.kill when available instead
of manually recursing through the cgroup tree.
Yu Watanabe [Thu, 28 May 2026 16:12:29 +0000 (01:12 +0900)]
units: drop Before=sockets.target from networkd resolve hook
Otherwise, it introduces cyclic dependencies:
```
systemd[1]: sockets.target: Found ordering cycle:
systemd-networkd-resolve-hook.socket/start after network-pre.target/start after
iptables.service/start after basic.target/start after sockets.target/start -
after systemd-networkd-resolve-hook.socket
systemd[1]: sockets.target: Job systemd-networkd-resolve-hook.socket/start deleted
to break ordering cycle starting with sockets.target/start
```
jeffhuang [Wed, 27 May 2026 18:08:38 +0000 (18:08 +0000)]
pe-binary: bound section data against file size, cap UKI zero-padding hash, validate optional header size
A hostile but structurally valid 382-byte PE32+ "EFI application" with a
single section whose VirtualSize is ~4 GiB and SizeOfRawData is 0 drives
uki_hash() into ~4.17 M iterations of SHA-256 over 1024 bytes of zeros
— wedging the parser for >10 s. Nine more slow-units share the same
shape. A separate MSAN finding from the new fuzzer (CIFuzz, memory
sanitizer) shows pe_load_headers() reading uninitialised heap memory
when SizeOfOptionalHeader is too small to actually contain
NumberOfRvaAndSizes.
Three tightenings in src/shared/pe-binary.c:
1. In pe_load_sections, reject sections whose PointerToRawData +
SizeOfRawData exceeds the actual file size. Raw section data must
fit inside the file; this is the parser-wide invariant
pe_hash / uki_hash / pe_read_section_data rely on.
2. In uki_hash, cap the (VirtualSize - SizeOfRawData) zero-padding
hash loop at 64 MiB. Real UKIs do not pad sections with tens of
MiB of zero-equivalent data; anything above this cap is a
malformed PE.
3. In pe_load_headers, reject a PE whose SizeOfOptionalHeader is too
small to cover up to NumberOfRvaAndSizes. Without this guard the
subsequent size-mismatch check reads uninitialised optional-header
bytes, caught by MSAN under CIFuzz.
Add the 382 B canonical reproducer (plus two structural siblings) and
the MSAN reproducer to test/fuzz/fuzz-pe-binary/. Also add a libFuzzer
harness in src/fuzz/fuzz-pe-binary.c and unit tests in
src/test/test-pe-binary.c that exercise each fix branch in isolation.
The 64 MiB hash boundary test is gated behind SYSTEMD_SLOW_TESTS so it
doesn't slow down emulated-arch CI.
This is a robustness fix, not a security fix: PE binaries consumed by
bootctl / systemd-stub / pcrlock / kernel-install / systemd-measure are
already trusted and signed at the consumer side, so the worst pre-fix
behaviour is wasted CPU on a UKI install / measure / inspect call.
Closes #42344.
Reported-by: AI-assisted libFuzzer campaign Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
We currently log at warning level:
/usr/lib/systemd/system/systemd-udevd.service:56: System call bpf cannot be
resolved as libseccomp is not available, ignoring: Operation not supported
In the initrd, or in minimal installations, not installing libseccomp is
reasonable, depending on various other choices. We shouldn't make fuss
about this.
profile.d: add instructions how to deactivate 80-systemd-osc-context.sh
This was requested in https://github.com/systemd/systemd/issues/42333.
Indeed, this integration is using three levels of systemd magick, so
doing this correctly is not obvious. Let's include specific instructions
to help people for whom this integration is causing problems.
fd-util: add wildcard_fd_is_valid() helper and use it tree-wide
Many *at()-style helpers accept a directory fd that may be either a
regular, valid fd (>= 0) or one of the special AT_FDCWD/XAT_FDROOT
wildcard values, and open-code that check in their assertions. Add a
wildcard_fd_is_valid() helper for it and use it tree-wide.
Malformed C [Wed, 27 May 2026 19:43:35 +0000 (22:43 +0300)]
nspawn: join network namespace before cloning user namespace
When both --private-users and --network-namespace-path are
specified, systemd-nspawn fails to start with "Operation not
permitted" during the setns() call.
This occurs because of the following execution sequence:
1. The outer child calls raw_clone() with CLONE_NEWUSER to create
the new user namespace.
2. The inner child is spawned inside this new user namespace.
3. The inner child then attempts to call setns() to join the
external network namespace.
Because the inner child is already running inside
the restricted user namespace, the kernel rejects
the setns() call to join a network namespace owned by
a different (host/more privileged) user namespace.
Fix this by moving the setns() call to the outer child, executing it
just before the raw_clone() call. This ensures the network namespace
is joined while the process still has the necessary privileges, which
also aligns with the inner child's expectation that the network
namespace is already set up upon entry.
Yu Watanabe [Thu, 28 May 2026 06:34:57 +0000 (15:34 +0900)]
fuzz-hwdb: shorten name of reproducers
The file name of the reproducer is used for test name, and the test name
is messed when the file name is too long.
Also, the mentioned issues are not regressions, but long standing bugs.
jeffhuang [Wed, 27 May 2026 18:41:54 +0000 (18:41 +0000)]
hwdb: bounds-check trie offsets against the mmap before dereferencing
Fixes a family of OOB reads in the trie walker where attacker-controlled
offsets are loaded from a (possibly hostile) hwdb.bin and added to
hwdb->map without first checking that the resulting pointer stays inside
the mapping. Crash sites:
Commit b45a897edc ("hwdb: reject out-of-bounds fnmatch prefixes")
plugged the first site only at the prefix_off-content level, but the
crash on the read of node->prefix_off itself still happens when node is
already OOB. This is the structural fix: a single hwdb_at() helper
validates that [off, off + size) lies inside the mapping, and
trie_node_from_off() / trie_string() return NULL on OOB; every caller
treats the result as nullable and surfaces -EBADMSG.
trie_fnmatch_f() additionally caps its recursion depth at 2048; without
the cap a corrupt trie whose child offsets form a cycle (or just a deep
linear chain) drives the parser into stack-overflow rather than
returning -EBADMSG (caught by CIFuzz address sanitizer on this branch).
Additions:
- A fuzz-hwdb libFuzzer harness that drives sd_hwdb_new_from_path,
sd_hwdb_get, sd_hwdb_seek, and sd_hwdb_enumerate on attacker bytes.
- Five hand-crafted unit tests in test-sd-hwdb.c (one per crash
bucket, plus the cyclic-trie recursion case) that build a malformed
in-memory hwdb.bin and assert -EBADMSG rather than SIGSEGV /
stack-overflow.
- Regression corpus files under test/fuzz/fuzz-hwdb/ pinning each
fixed bucket, including the CIFuzz stack-overflow reproducer.
Luca Boccassi [Wed, 27 May 2026 22:32:02 +0000 (23:32 +0100)]
test-oomd: drop racy last_had_mem_reclaim assertion
test_oomd_cgroup_context_acquire_and_insert sets c1->pgscan = UINT64_MAX
and c1->last_had_mem_reclaim = 888 before re-inserting via
oomd_insert_cgroup_context(h1, h2, cgroup), then asserts that c2 carries
over last_had_mem_reclaim == 888.
The assumption was that, because c1->pgscan (which becomes c2->last_pgscan)
is UINT64_MAX and is therefore strictly greater than the freshly-acquired
c2->pgscan, oomd_pgscan_rate() in oomd_insert_cgroup_context() would
return 0 and leave last_had_mem_reclaim untouched. But the function
treats last_pgscan > pgscan as "cgroup was recreated", resets last_pgscan
to 0, and returns pgscan - 0 == pgscan. So when the kernel records any
non-zero pgscan on the live cgroup of the test unit, the rate is > 0 and
last_had_mem_reclaim is overwritten with now(CLOCK_MONOTONIC).
From src/oom/oomd-util.c:
uint64_t oomd_pgscan_rate(const OomdCGroupContext *c) {
[...]
last_pgscan = c->last_pgscan;
if (c->last_pgscan > c->pgscan) {
log_debug("Last pgscan %"PRIu64" greater than current pgscan %"PRIu64" for %s. Using last pgscan of zero.",
c->last_pgscan, c->pgscan, c->path);
last_pgscan = 0;
}
return c->pgscan - last_pgscan;
}
int oomd_insert_cgroup_context(Hashmap *old_h, Hashmap *new_h, const char *path) {
[...]
if (oomd_pgscan_rate(curr_ctx) > 0)
curr_ctx->last_had_mem_reclaim = now(CLOCK_MONOTONIC);
Under sanitizers the test can be slow enough that the kernel scans the
test service cgroup at least once between the two acquisitions, which
triggers the failure:
[ 1898.159455] test-oomd-util[2606]: /* test_oomd_cgroup_context_acquire_and_insert */
[ 1898.161247] test-oomd-util[2606]: Last pgscan 18446744073709551615 greater than current pgscan 2 for /system.slice/test-oomd-util.service. Using last pgscan of zero.
[ 1898.161330] test-oomd-util[2606]: src/oom/test-oomd-util.c:322: Assertion failed: Expected "c2->last_had_mem_reclaim == 888u", but 1898161250 != 888
(1898161250 matches the monotonic timestamp of the log line, confirming
that last_had_mem_reclaim was overwritten with now(CLOCK_MONOTONIC).)
The propagation of last_had_mem_reclaim is already covered
deterministically by TEST(oomd_update_cgroup_contexts_between_hashmaps),
which builds OomdCGroupContext structs directly with matching pgscan
values so that oomd_pgscan_rate() returns exactly 0. So just drop the
racy setup and assertion here.
Yu Watanabe [Wed, 27 May 2026 15:33:35 +0000 (00:33 +0900)]
test-pressure: set timeout to make not wait forever
If this runs on a slow or busy machine, then we may not get enough
pressure to trigger the event sources. In such case, the test does not
finish. It is problematic when the test is _not_ run with 'meson test',
e.g. debian/ubuntu CIs.
Let's introduce a timeout for each event loop, and skip test cases
gracefully.
Chris Patterson [Tue, 26 May 2026 15:04:28 +0000 (15:04 +0000)]
udev: preserve rule-set properties on failed network interface rename
When rename_netif() failed for a reason other than -EBUSY (e.g. -EEXIST
because NAME= conflicts with an existing interface), the revert path
rewrote the on-disk udev database from dev_db_clone (the pre-rules
snapshot) and then returned the error. The caller in
udev_event_execute_rules() bailed out before reaching the final
device_update_db(dev), so every property the rules had attached to the
device during this event (including ENV{}= assignments made alongside
the failing NAME=) was silently dropped from /run/udev/data/.
Persist 'dev' from inside the revert block, after its syspath and
INTERFACE have been restored. The cloned snapshot is still written
first to clear ID_RENAMING/ID_PROCESSING; the subsequent dev write
keeps the rule-applied properties without resurrecting the new name.
Only persist when r < 0, since the -EBUSY path returns success and the
caller will write the DB itself.
Add a TEST-17-UDEV.rename-netif regression test that pre-creates the
rename target, then triggers rules that set three ENV{}= properties
(one on a rule line before the failing NAME=, one on the same line as
NAME=, and one on a rule line after) and asserts all three are still
visible via udevadm info on the source interface. The neighbouring
test_netif_renaming_conflict already exercises the same -EEXIST revert
path but only checks the SYSTEMD_ALIAS broadcast, which is why this
regression went unnoticed.
Verified against unpatched origin/main (b4aff10ac0): the new test
fails, udevadm reports only kernel-supplied fields for the source
interface, and /run/udev/data/n<ifindex> is 0 bytes. With this patch
applied all three properties survive regardless of whether they were
set before, on, or after the failing NAME= rule line.
Downstream impact (NetworkManager managing an interface that rules had
marked NM_UNMANAGED=1): https://redhat.atlassian.net/browse/RHEL-178481
Fixes: https://github.com/systemd/systemd/issues/42331 Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Yu Watanabe [Wed, 27 May 2026 16:41:48 +0000 (01:41 +0900)]
test-qmp-client: drop QMP_TEST() macro
Similar to the previous commit for test-path.
The macro confuses gcc/gcov/lcov:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_qmp_client_basic_body at
/home/runner/work/systemd/systemd/src/test/test-qmp-client.c:204:
204 -> 224 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-qmp-client.p/src_test_test-qmp-client.c.gcno
```
The macro itself is not bad, but does not reduce lines so much.
Let's stop using the macro.
Frantisek Sumsal [Wed, 27 May 2026 13:03:26 +0000 (15:03 +0200)]
import: don't assert on missing signature file
Since ac9edf991142c1597c8d86431ee9bd50c21bce41 even the per-file
verification style uses detached signatures instead of inline ones.
That commit dropped the inline verification fallback, but it didn't
update the raw_pull_job_on_finished()/tar_pull_job_on_finished()
callbacks, which caused the per-file verification to silently fall
through the signature check and eventually hit the now unconditional
assert in pull_verify():
~# importctl pull-tar -mN https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz
...
Acquired 1.2G for https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz.
Download of https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz complete.
SHA256 checksum of https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz is valid.
Assertion 'signature_job->state == PULL_JOB_DONE' failed at src/import/pull-common.c:588, function pull_verify(). Aborting.
To fix this, let's drop the now outdated guards from the callbacks,
given that both per-file and per-directory verification uses detached
signatures. Also, drop some dead code along the way, given we no longer
need to even determine the verification style anymore.
With this, the reproducer above now shows a proper error:
...
Acquired 1.2G for https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz.
Download of https://distfiles.gentoo.org/releases/amd64/autobuilds/20260426T153103Z/stage3-amd64-systemd-20260426T153103Z.tar.xz complete.
Failed to retrieve signature file, cannot verify. (Try --verify=no?)
Also, both --verify=checksum/--verify=no keep working as expected.
Yu Watanabe [Wed, 27 May 2026 14:29:31 +0000 (23:29 +0900)]
test-path: drop PATH_TEST() macro
The macro was introduced by fc7a32df38dd4797ce7266df6ece6bd9b9842783,
but unfortunately gcc/gcov/lcov are confused by the macro:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at
/home/runner/work/systemd/systemd/src/test/test-path.c:158:
158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
```
The macro deos nothing spurious, hence it should be a bug in gcc.
But, the macro just reduces the lines for calling setup_test(), and
does not simplify test cases so much.
Let's call it in each test cases, and stop using the macro.
Frantisek Sumsal [Wed, 27 May 2026 14:07:23 +0000 (16:07 +0200)]
Translations update from Fedora Weblate (#42334)
Translations update from [Fedora
Weblate](https://translate.fedoraproject.org) for
[systemd/main](https://translate.fedoraproject.org/projects/systemd/main/).
Rocker Zhang [Fri, 15 May 2026 11:27:57 +0000 (19:27 +0800)]
man: clarify that ExecCondition= skip triggers SuccessAction=
Unit-level Condition…= / Assert…= directives that fail prevent activation
entirely, so SuccessAction= / FailureAction= never fire. An ExecCondition=
skip in [Service] runs as part of the activation transition itself, so
the unit goes active → inactive and SuccessAction= is honored.
This asymmetry has tripped users up; document it explicitly in both
systemd.service(5) (ExecCondition= section) and systemd.unit(5)
(SuccessAction= / FailureAction= section) with cross-references.
Fixes: https://github.com/systemd/systemd/issues/42035 Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Luca Boccassi [Wed, 27 May 2026 10:47:21 +0000 (11:47 +0100)]
Fix coverage CI job (#42322)
It has been failing for a few days:
```
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at /home/runner/work/systemd/systemd/src/test/test-path.c:158: 158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
```
Luca Boccassi [Tue, 26 May 2026 19:15:45 +0000 (20:15 +0100)]
test: disable ManagedOOMMemoryPressure on /system.slice in TEST-55-OOMD
The systemd-oomd-defaults rpm installed on Fedora/CentOS images via
mkosi/mkosi.conf.d/centos-fedora/mkosi.conf ships
/usr/lib/systemd/system/system.slice.d/10-oomd-per-slice-defaults.conf:
In a recent flaky CI run on centos-10, the following sequence was
recorded in test/journal/TEST-55-OOMD-1.journal:
[ 77.740597] systemd-oomd[659]: Memory pressure for /system.slice is 85.03% > 80.00% for > 2s with reclaim activity
[ 77.745326] TEST-55-OOMD.sh[1292]: + journalctl --sync
[ 77.749125] systemd-oomd[659]: Considered 19 cgroups for killing, top candidates were:
[ 77.749128] systemd-oomd[659]: Path: /system.slice/systemd-journald.service
[ 77.749134] systemd-oomd[659]: Current Memory Usage: 55.5M
[ 77.749597] systemd-oomd[659]: oomd attempting to kill 407 with KILL
[ 77.749670] systemd-oomd[659]: Marked /system.slice/systemd-journald.service for killing due to memory pressure for /system.slice being 85.03% > 80.00% for > 2s with reclaim activity
[ 77.752252] systemd[1]: systemd-journald.service: systemd-oomd killed 1 process(es) in this unit.
[ 77.752293] systemd[1]: systemd-journald.service: Changed running -> stop-sigterm
[ 329.922401] systemd[1]: systemd-journald.service: Main process exited, code=killed, status=9/KILL
PID 1292 (the test script) never logged anything after the
`journalctl --sync` line at [77.745326], and the unit stayed in
stop-sigterm until [329.922401].
Override /system.slice to ManagedOOMMemoryPressure=auto in the test
setup so the test does not rely on whichever per-slice oomd defaults
the distro happens to ship.
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
Luca Boccassi [Tue, 26 May 2026 19:23:25 +0000 (20:23 +0100)]
test: ignore lcov errors due to inconsistency
lcov: ERROR: lcov: ERROR: (inconsistent) mismatched end line for test_path_exists_body at /home/runner/work/systemd/systemd/src/test/test-path.c:158: 158 -> 185 while capturing from build/mkosi.builddir/arch~rolling~x86-64/test-path.p/src_test_test-path.c.gcno
(use "lcov --ignore-errors inconsistent ..." to bypass this error)
Other places that read credentials filer out ENXIO:
$ journalctl -b -u systemd-imds-early-network.service -o short-monotonic --no-hostname --no-pager -p warning
[ 5.477675] systemd-imdsd[473]: Failed to read credential 'imds.vendor', ignoring: No such device or address
[ 5.477687] systemd-imdsd[473]: Failed to read credential 'imds.vendor_token', ignoring: No such device or address
[ 5.477693] systemd-imdsd[473]: Failed to read credential 'imds.refresh_header_name', ignoring: No such device or address
[ 5.477699] systemd-imdsd[473]: Failed to read credential 'imds.data_url', ignoring: No such device or address
[ 5.477704] systemd-imdsd[473]: Failed to read credential 'imds.data_url_suffix', ignoring: No such device or address
[ 5.477710] systemd-imdsd[473]: Failed to read credential 'imds.token_header_name', ignoring: No such device or address
[ 5.477714] systemd-imdsd[473]: Failed to read credential 'imds.extra_header', ignoring: No such device or address
[ 5.477720] systemd-imdsd[473]: Failed to read credential 'imds.extra_header2', ignoring: No such device or address
[ 5.477730] systemd-imdsd[473]: Failed to read credential 'imds.extra_header3', ignoring: No such device or address
[ 5.477736] systemd-imdsd[473]: Failed to read credential 'imds.extra_header4', ignoring: No such device or address
[ 5.477742] systemd-imdsd[473]: Failed to read credential 'imds.extra_header5', ignoring: No such device or address
[ 5.477747] systemd-imdsd[473]: Failed to read credential 'imds.extra_header6', ignoring: No such device or address
[ 5.477751] systemd-imdsd[473]: Failed to read credential 'imds.extra_header7', ignoring: No such device or address
[ 5.477757] systemd-imdsd[473]: Failed to read credential 'imds.extra_header8', ignoring: No such device or address
[ 5.477763] systemd-imdsd[473]: Failed to read credential 'imds.extra_header9', ignoring: No such device or address
[ 5.477768] systemd-imdsd[473]: Failed to read credential 'imds.extra_header10', ignoring: No such device or address
[ 5.477774] systemd-imdsd[473]: Failed to read credential 'imds.extra_header11', ignoring: No such device or address
[ 5.477779] systemd-imdsd[473]: Failed to read credential 'imds.extra_header12', ignoring: No such device or address
[ 5.477784] systemd-imdsd[473]: Failed to read credential 'imds.extra_header13', ignoring: No such device or address
[ 5.477789] systemd-imdsd[473]: Failed to read credential 'imds.extra_header14', ignoring: No such device or address
[ 5.477799] systemd-imdsd[473]: Failed to read credential 'imds.extra_header15', ignoring: No such device or address
[ 5.477804] systemd-imdsd[473]: Failed to read credential 'imds.extra_header16', ignoring: No such device or address
[ 5.477810] systemd-imdsd[473]: Failed to read credential 'imds.extra_header17', ignoring: No such device or address
[ 5.477815] systemd-imdsd[473]: Failed to read credential 'imds.extra_header18', ignoring: No such device or address
[ 5.477820] systemd-imdsd[473]: Failed to read credential 'imds.extra_header19', ignoring: No such device or address
[ 5.477825] systemd-imdsd[473]: Failed to read credential 'imds.extra_header20', ignoring: No such device or address
[ 5.477830] systemd-imdsd[473]: Failed to read credential 'imds.extra_header21', ignoring: No such device or address
[ 5.477835] systemd-imdsd[473]: Failed to read credential 'imds.extra_header22', ignoring: No such device or address
[ 5.477840] systemd-imdsd[473]: Failed to read credential 'imds.extra_header23', ignoring: No such device or address
[ 5.477845] systemd-imdsd[473]: Failed to read credential 'imds.extra_header24', ignoring: No such device or address
[ 5.477851] systemd-imdsd[473]: Failed to read credential 'imds.extra_header25', ignoring: No such device or address
[ 5.477856] systemd-imdsd[473]: Failed to read credential 'imds.extra_header26', ignoring: No such device or address
[ 5.477865] systemd-imdsd[473]: Failed to read credential 'imds.extra_header27', ignoring: No such device or address
[ 5.477869] systemd-imdsd[473]: Failed to read credential 'imds.extra_header28', ignoring: No such device or address
[ 5.477874] systemd-imdsd[473]: Failed to read credential 'imds.extra_header29', ignoring: No such device or address
[ 5.477881] systemd-imdsd[473]: Failed to read credential 'imds.extra_header30', ignoring: No such device or address
[ 5.477885] systemd-imdsd[473]: Failed to read credential 'imds.extra_header31', ignoring: No such device or address
[ 5.477890] systemd-imdsd[473]: Failed to read credential 'imds.extra_header32', ignoring: No such device or address
[ 5.477896] systemd-imdsd[473]: Failed to read credential 'imds.extra_header33', ignoring: No such device or address
[ 5.477901] systemd-imdsd[473]: Failed to read credential 'imds.extra_header34', ignoring: No such device or address
[ 5.477906] systemd-imdsd[473]: Failed to read credential 'imds.extra_header35', ignoring: No such device or address
[ 5.477913] systemd-imdsd[473]: Failed to read credential 'imds.extra_header36', ignoring: No such device or address
[ 5.477917] systemd-imdsd[473]: Failed to read credential 'imds.extra_header37', ignoring: No such device or address
[ 5.477922] systemd-imdsd[473]: Failed to read credential 'imds.extra_header38', ignoring: No such device or address
[ 5.477931] systemd-imdsd[473]: Failed to read credential 'imds.extra_header39', ignoring: No such device or address
[ 5.477935] systemd-imdsd[473]: Failed to read credential 'imds.extra_header40', ignoring: No such device or address
[ 5.477940] systemd-imdsd[473]: Failed to read credential 'imds.extra_header41', ignoring: No such device or address
[ 5.477945] systemd-imdsd[473]: Failed to read credential 'imds.extra_header42', ignoring: No such device or address
[ 5.477951] systemd-imdsd[473]: Failed to read credential 'imds.extra_header43', ignoring: No such device or address
[ 5.477956] systemd-imdsd[473]: Failed to read credential 'imds.extra_header44', ignoring: No such device or address
[ 5.477962] systemd-imdsd[473]: Failed to read credential 'imds.extra_header45', ignoring: No such device or address
[ 5.477967] systemd-imdsd[473]: Failed to read credential 'imds.extra_header46', ignoring: No such device or address
[ 5.477972] systemd-imdsd[473]: Failed to read credential 'imds.extra_header47', ignoring: No such device or address
[ 5.477978] systemd-imdsd[473]: Failed to read credential 'imds.extra_header48', ignoring: No such device or address
[ 5.477982] systemd-imdsd[473]: Failed to read credential 'imds.extra_header49', ignoring: No such device or address
[ 5.477988] systemd-imdsd[473]: Failed to read credential 'imds.extra_header50', ignoring: No such device or address
[ 5.477995] systemd-imdsd[473]: Failed to read credential 'imds.extra_header51', ignoring: No such device or address
[ 5.477999] systemd-imdsd[473]: Failed to read credential 'imds.extra_header52', ignoring: No such device or address
[ 5.478022] systemd-imdsd[473]: Failed to read credential 'imds.extra_header53', ignoring: No such device or address
[ 5.478028] systemd-imdsd[473]: Failed to read credential 'imds.extra_header54', ignoring: No such device or address
[ 5.478033] systemd-imdsd[473]: Failed to read credential 'imds.extra_header55', ignoring: No such device or address
[ 5.478039] systemd-imdsd[473]: Failed to read credential 'imds.extra_header56', ignoring: No such device or address
[ 5.478044] systemd-imdsd[473]: Failed to read credential 'imds.extra_header57', ignoring: No such device or address
[ 5.478050] systemd-imdsd[473]: Failed to read credential 'imds.extra_header58', ignoring: No such device or address
[ 5.478055] systemd-imdsd[473]: Failed to read credential 'imds.extra_header59', ignoring: No such device or address
[ 5.478060] systemd-imdsd[473]: Failed to read credential 'imds.extra_header60', ignoring: No such device or address
[ 5.478066] systemd-imdsd[473]: Failed to read credential 'imds.extra_header61', ignoring: No such device or address
[ 5.478071] systemd-imdsd[473]: Failed to read credential 'imds.extra_header62', ignoring: No such device or address
[ 5.478079] systemd-imdsd[473]: Failed to read credential 'imds.extra_header63', ignoring: No such device or address
[ 5.478086] systemd-imdsd[473]: Failed read IPv4 address from credential 'imds.address_ipv4', ignoring: No such device or address
[ 5.478091] systemd-imdsd[473]: Failed read IPv6 address from credential 'imds.address_ipv6', ignoring: No such device or address
[ 5.478097] systemd-imdsd[473]: Failed to read credential 'imds.key_hostname', ignoring: No such device or address
[ 5.478102] systemd-imdsd[473]: Failed to read credential 'imds.key_region', ignoring: No such device or address
[ 5.478107] systemd-imdsd[473]: Failed to read credential 'imds.key_zone', ignoring: No such device or address
[ 5.478113] systemd-imdsd[473]: Failed to read credential 'imds.key_ipv4_public', ignoring: No such device or address
[ 5.478119] systemd-imdsd[473]: Failed to read credential 'imds.key_ipv6_public', ignoring: No such device or address
[ 5.478123] systemd-imdsd[473]: Failed to read credential 'imds.key_ssh_key', ignoring: No such device or address
[ 5.478128] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata', ignoring: No such device or address
[ 5.478134] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata_base', ignoring: No such device or address
[ 5.478137] systemd-imdsd[473]: Failed to read credential 'imds.key_userdata_base64', ignoring: No such device or address
In https://bugzilla.redhat.com/show_bug.cgi?id=2481466, it is reported
that systemd-imds-early-network.service fails on AWS EC2 instance with:
> No IMDS endpoint information provided or detected, cannot operate.
The service will be started on various systems where it doesn't have
enough configuration to run. The systemd-imds-generator only does some
superficial checks, so the tool should not mark the boot as failed
it turns out that IMDS is not supported.
Yu Watanabe [Tue, 26 May 2026 15:51:26 +0000 (00:51 +0900)]
udev: ignore errors in adding property with spurious value
Since a62cd5a153ffe18c27aff02685ed75c5bc4509a2, when an invalid property
is being added, device_add_property() refuses it with -EINVAL.
Before the commit, the function could fail with only -ENOMEM, and if it fails,
processing udev rules was aborted.
Let's not hard fail when udev rules or udev builtins try to add an invalid
property, and let's just log and ignore the failure.
* 9cb09470c9 Version 261~rc1
* 7d16ad00bd Fix compilation with openssl 4.0
* 3770fa7c92 Revert "Use dlopen-notes to automatically generate library Recommends/Requires/Suggests"
* 8b3d1726f5 Add back various explit Requires
* d8abb91805 Drop scriptlet workarounds for upgrades from versions < 247
* ee6d0b9d27 Use dlopen-notes to automatically generate library Recommends/Requires/Suggests
* 32a2038627 spec: drop duplicated line
* ab743db0fe Downgrade kbd dependency to Recommends
* 400494ada4 Update conditionals for RHEL 11
Luca Boccassi [Tue, 26 May 2026 12:23:37 +0000 (13:23 +0100)]
test: clean up persistent test state at beginning of TEST-64-UDEV-STORAGE too
This test often fails because the VM reboots (eg: kernel panic) and the
previous state is left unclean. Do the cleanups at the beginning too,
to try and reduce flakiness.
projects / thirdparty / systemd.git / log
