dnsmasq 2.92 started converting binary content to ascii so the previous
invalid URL is no longer invalid as it's escaped.
So the test started failing: https://bugs.debian.org/1122015
Use a '|' character instead, which is not a valid URL character but it's
also not escaped by dnsmasq.
Follow-up for 1219391c9f
(cherry picked from commit e2fbcee030)
It is a firewall service used in postmarketOS.
When it is active, then e.g. DHCP packets are filtered, and many
tests will be failed.
(cherry picked from commit 193626bd8b)
After bdb8e584f4 we stopped rebasing the
next elapse timestamp unconditionally and the only case where we'd do
that was when both last trigger and last inactive timestamps were empty.
This covered timer units during boot just fine, since they would have
neither of those timestamps set. However, persistent timers
(Persistent=yes) store their last trigger timestamp on a persistent
storage and load it back after reboot, so the rebasing was skipped in
this case.
To mitigate this, check the last_trigger timestamp is older than the
current machine boot - if so, that means that it came from a stamp file
of a persistent timer unit and we need to rebase it to make
RandomizedDelaySec= work properly.
Follow-up for bdb8e584f4.
Resolves: #39739
(cherry picked from commit 3605b3ba87)
Add support for an empty Gateway= in [Network] to clear the existing
routes. This change will allow users to remove the default route from a
drop-in file.
(cherry picked from commit 5b0e262f45)
Match the behaviour of the other test classes that use sd-run and
always create the mock tmpfs runtime dirs.
This will be needed as the new resolve.hook directory won't exist
on boot but will be needed by the test case.
(cherry picked from commit f041d40dee)
There is a TOCTOU in the `systemctl status` where a unit might change
its state during the initial ListUnitsByPatterns call and the subsequent
individual GetAll calls, which then makes the systemctl call fail even
if the unit that was originally pulled in was active/running:
[ 1922.040463] TEST-26-SYSTEMCTL.sh[117]: + systemctl status -a --state active,running,plugged
[ 1922.051423] systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=ListUnitsByPatterns cookie=1 reply_cookie=0 signature=asas error-name=n/a error-message=n/a
[ 1922.052501] systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=a(ssssssouso) error-name=n/a error-message=n/a
[ 1922.052650] systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1/unit/_2d_2emount interface=org.freedesktop.DBus.Properties member=GetAll cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a
...
[ 1922.222061] systemd-hostnamed[424]: Idle for 30s, exiting.
...
[ 1922.224961] systemd[1]: systemd-hostnamed.service: Got notification message from PID 424: STOPPING=1, STATUS=Shutting down...
[ 1922.224983] systemd[1]: systemd-hostnamed.service: Changed running ->stop-sigterm
...
[ 1922.228984] systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1/unit/systemd_2dhostnamed_2eservice interface=org.freedesktop.DBus.Properties member=GetAll cookie=41 reply_cookie=0 signature=s error-name=n/a error-message=n/a
[ 1922.234402] systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=43 reply_cookie=41 signature=a{sv} error-name=n/a error-message=n/a
Since in this case we care mostly about the code paths the command
triggers, ignore its exit code as we do for the previous one.
Resolves: #39612
(cherry picked from commit b131e8d3a4)
As registering the container creates a scope which might not be cleaned
up completely before we run a next command in the same container,
causing intermittent test fails:
[ 63.424739] TEST-13-NSPAWN.sh[4231]: + systemd-nspawn --directory=/var/lib/machines/TEST-13-NSPAWN.sanity.zH2 bash -xec '[[ $USER == root ]]'
[ 63.427504] systemd-nspawn[4381]: ░ Spawning container TEST-13-NSPAWN.sanity.zH2 on /var/lib/machines/TEST-13-NSPAWN.sanity.zH2.
[ 63.437154] systemd[1]: Started TEST-13-NSPAWN.sanity.zH2.scope - Container TEST-13-NSPAWN.sanity.zH2.
[ 63.437765] systemd-machined[1164]: New machine TEST-13-NSPAWN.sanity.zH2.
[ 63.440311] TEST-13-NSPAWN.sh[4381]: + [[ root == root ]]
[ 63.442046] systemd[1]: TEST-13-NSPAWN.sanity.zH2.scope: Killed unit cgroup '/machine.slice/TEST-13-NSPAWN.sanity.zH2.scope' with SIGKILL on client request.
[ 63.442583] systemd-nspawn[4381]: Container TEST-13-NSPAWN.sanity.zH2 exited successfully.
[ 63.443073] systemd-machined[1164]: Machine TEST-13-NSPAWN.sanity.zH2 terminated.
[ 63.448728] TEST-13-NSPAWN.sh[4231]: + systemd-nspawn --directory=/var/lib/machines/TEST-13-NSPAWN.sanity.zH2 --user=testuser bash -xec '[[ $USER == testuser ]]'
[ 63.451209] systemd-nspawn[4385]: ░ Spawning container TEST-13-NSPAWN.sanity.zH2 on /var/lib/machines/TEST-13-NSPAWN.sanity.zH2.
[ 63.455295] systemd-nspawn[4385]: Failed to allocate scope: Unit TEST-13-NSPAWN.sanity.zH2.scope was already loaded or has a fragment file.
[ 63.456139] systemd[1]: TEST-13-NSPAWN.sanity.zH2.scope: Deactivated successfully.
[ 63.461292] TEST-13-NSPAWN.sh[2839]: + at_exit
Since even systemd-nspawn's man page suggests not to register containers
with systemd-machined if they don't run a service manager, let's do just
that to mitigate the race.
Resolves: #39629
(cherry picked from commit 6a05abb9b4)
The same service name was accidentally used for two invocations:
```
[ 1801.197993] H TEST-04-JOURNAL.sh[20563]: + assert_rc 0 journalctl -q -D /run/log/journal/e30adae55e664d328af442bf5df694c8/ -u test-23833.service --grep service=test-23833.service
[ 1801.198527] H TEST-04-JOURNAL.sh[20685]: + set +ex
[ 1801.222676] H TEST-04-JOURNAL.sh[20686]: Nov 10 03:18:51 H systemd[1]: test-23833.service: About to execute: /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync"
[ 1801.222676] H TEST-04-JOURNAL.sh[20686]: Nov 10 03:18:51 H systemd[1]: Started test-23833.service - [systemd-run] /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync".
[ 1801.222676] H TEST-04-JOURNAL.sh[20686]: Nov 10 03:18:51 H (bash)[20681]: test-23833.service: Executing: /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync"
[ 1801.222676] H TEST-04-JOURNAL.sh[20686]: Nov 10 03:18:51 H bash[20681]: service=test-23833.service invocation=1866f15e95924a688dcecde72bf345f6
[ 1801.227878] H TEST-04-JOURNAL.sh[20563]: + assert_rc 1 journalctl -q -D /var/log/journal/e30adae55e664d328af442bf5df694c8/ -u test-23833.service --grep service=test-23833.service
[ 1801.228265] H TEST-04-JOURNAL.sh[20689]: + set +ex
[ 1801.253412] H TEST-04-JOURNAL.sh[20690]: Nov 10 03:18:49 H systemd[1]: test-23833.service: About to execute: /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync"
[ 1801.253412] H TEST-04-JOURNAL.sh[20690]: Nov 10 03:18:49 H systemd[1]: Started test-23833.service - [systemd-run] /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync".
[ 1801.253412] H TEST-04-JOURNAL.sh[20690]: Nov 10 03:18:49 H (bash)[20581]: test-23833.service: Executing: /usr/bin/bash -c "echo service=test-23833.service invocation=\$INVOCATION_ID; journalctl --sync"
[ 1801.253412] H TEST-04-JOURNAL.sh[20690]: Nov 10 03:18:49 H bash[20581]: service=test-23833.service invocation=a3089a62b5624d21bac0a75a3995d8b5
[ 1801.258158] H TEST-04-JOURNAL.sh[20692]: FAIL: expected: '1' actual: '0'
```
(cherry picked from commit 1d17b23dd6)
Occasionally there are truncated journals failing this test:
[ 884.181701] H TEST-04-JOURNAL.sh[12104]: ++ journalctl --no-hostname -n 1 -t bash --invocation=fe8122a7d8eb42c7bf357ac5fafa95e1
[ 884.181749] H TEST-04-JOURNAL.sh[12091]: + assert_in 'invocation 1 fe8122a7d8eb42c7bf357ac5fafa95e1' 'Nov 06 17:27:10 bash[11985]: invocation 1 fe8122a7d8eb42c7bf357ac5fafa95e1'
[ 884.181773] H TEST-04-JOURNAL.sh[12105]: + set +ex
[ 884.181819] H TEST-04-JOURNAL.sh[12091]: + read -r idx invocation _
[ 884.181819] H TEST-04-JOURNAL.sh[12091]: + i=2
[ 884.181865] H TEST-04-JOURNAL.sh[12106]: ++ journalctl --no-hostname -n 1 -t bash --invocation=2 -u invocation-id-test-20992
[ 884.181865] H TEST-04-JOURNAL.sh[12106]: Journal file /var/log/journal/936183a66e7c47939693ae37a967e4fd/system.journal is truncated, ignoring file.
[ 884.181865] H TEST-04-JOURNAL.sh[12106]: No journal entry found for the invocation (+2).
[ 884.181952] H TEST-04-JOURNAL.sh[12091]: + assert_in 'invocation 2 07d0bd6b5c654b148541d798abccaa96' ''
[ 884.181972] H TEST-04-JOURNAL.sh[12107]: + set +ex
[ 884.181972] H TEST-04-JOURNAL.sh[12107]: FAIL: 'invocation 2 07d0bd6b5c654b148541d798abccaa96' not found in:
Rotate it at the beginning of the test case to try and avoid this.
Fixes https://github.com/systemd/systemd/issues/39601
(cherry picked from commit 2db3e403ae)
When we moved the time to 1 minute after the timer would've elapsed,
systemd could pick RandomizedDelaySec= <= 1 minute which would then
cause the timer to elapse immediately and the InactiveExitTimestamp=
to get recalculated including a new next elapse time that would be for
the next "window":
systemd[1]: timer-RandomizedDelaySec-30785.timer: Adding 3.634672s random time.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Realtime timer elapses at Fri 2025-11-07 00:10:03 UTC.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Timer elapsed.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Changed waiting -> running
systemd[1]: Found unit timer-RandomizedDelaySec-30785.timer at /run/systemd/system/timer-RandomizedDelaySec-30785.timer (regular file)
systemd[1]: Preset files say disable timer-RandomizedDelaySec-30785.timer.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Got notified about unit deactivation.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Adding 8h 39min 26.166418s random time.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Realtime timer elapses at Sat 2025-11-08 08:49:26 UTC.
systemd[1]: timer-RandomizedDelaySec-30785.timer: Changed running -> waiting
...
TEST-53-TIMER.sh[1008]: InactiveExitTimestamp=Thu 2025-11-06 23:00:00 UTC
TEST-53-TIMER.sh[1010]: ++ systemctl show -P NextElapseUSecRealtime timer-RandomizedDelaySec-30785.timer
TEST-53-TIMER.sh[905]: + NEXT_ELAPSE_REALTIME='Sat 2025-11-08 08:49:26 UTC'
TEST-53-TIMER.sh[1011]: ++ date '--date=Sat 2025-11-08 08:49:26 UTC' +%s
TEST-53-TIMER.sh[905]: + NEXT_ELAPSE_REALTIME_S=1762591766
TEST-53-TIMER.sh[905]: + : 'Next elapse timestamp should be Fri 2025-11-07 00:10:00 UTC <= Sat 2025-11-08 08:49:26 UTC <= Fri 2025-11-07 22:10:00 UTC'
TEST-53-TIMER.sh[905]: + assert_ge 1762591766 1762474200
TEST-53-TIMER.sh[1012]: + set +ex
TEST-53-TIMER.sh[905]: + assert_le 1762591766 1762553400
TEST-53-TIMER.sh[1013]: + set +ex
TEST-53-TIMER.sh[1013]: FAIL: '1762591766' > '1762553400'
Technically, the race is still there, but the window for it should be
_much_ smaller now (< 1s on a reasonably fast system). Let's hope that's
enough.
Resolves: #39594
(cherry picked from commit 6d510012b7)
Do not set a timeout on the wait-online call, since there are timeout
calls later that will prevent the test from blocking forever. Increase
those timeout calls for slower CI runs.
(cherry picked from commit 40a6069f9a)
This test is flaky on the infrastructure due to this setup step timing
out. As a naive step, just increase the timeout to 60s.
Part 1 of #39602
(cherry picked from commit be394fcaff)
The current test is flaky because it creates a new interface definition,
calls networkctl reload, and then calls resolvectl show-cache. If
resolved has not received the changes and setup the DNS scopes for the
interface, show-cache will be empty for that interface.
Part 2 of #39602
(cherry picked from commit 3d6eb1ed42)
The EnterNamespace= feature currently doesn't work if the debuginfo is
separated from the crashing binary. Until that's resolved, let's run the
test only if the test binary has embedded debuginfo (.debug_info
section; e.g. when systemd is built without WITH_DEBUG=1) or it contains
MiniDebugInfo (.gnu_debugdata section; default on Fedora and CentOS).
See: https://github.com/systemd/systemd/pull/39268#issuecomment-3390745718
(cherry picked from commit 80b4cacf1b)
So we don't have to pull in gcc and other stuff into it.
Also, make the test itself a bit more robust and debug-able.
(cherry picked from commit 937f609b41)
This also makes shebang always use env command, and drops unnecessary
'bash -c' or 'sh -c' when a signle command is invoked in the shell,
like sleep or echo.
(cherry picked from commit e2c5e9c011)
In these two cases we need to sync the journal _after_ the unit finishes
as well, because we try to match messages from systemd itself, not
(only) from the unit, and the messages about units are dispatched
asynchronously.
That is, in the first case (silent-success.service) we want to make sure
that LogLevelMax= filters out messages _about_ units (from systemd) as
well, including messages like "Deactivated..." and "Finished...", which
are sent out only when/after the unit is stopped.
In the second case we try to match messages with the "systemd" syslog
tag, but these messages come from systemd (obviously) and are sent out
asynchronously, which means they might not reach the journal before we
call `journalctl --sync` from the test unit itself, like happened here:
[ 1754.150391] TEST-04-JOURNAL.sh[13331]: + systemctl start verbose-success.service
[ 1754.172256] bash[13692]: success
[ 1754.221210] TEST-04-JOURNAL.sh[13694]: ++ journalctl -b -q -u verbose-success.service -t systemd
[ 1754.221493] TEST-04-JOURNAL.sh[13331]: + [[ -n '' ]]
[ 1754.175709] systemd[1]: Starting verbose-success.service - Verbose successful service...
[ 1754.221697] TEST-04-JOURNAL.sh[122]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/TEST-04-JOURNAL.journal.sh failed'
[ 1754.221697] TEST-04-JOURNAL.sh[122]: Subtest /usr/lib/systemd/tests/testdata/units/TEST-04-JOURNAL.journal.sh failed
[ 1754.221697] TEST-04-JOURNAL.sh[122]: + return 1
[ 1754.205408] systemd[1]: verbose-success.service: Deactivated successfully.
[ 1754.205687] systemd[1]: Finished verbose-success.service - Verbose successful service.
By syncing the journal after the unit is stopped we have much bigger
chance that the systemd messages already reached the journal - the race
is technically still there, but the chance we'd hit it should be pretty
negligible.
Resolves: #39555
(cherry picked from commit 7b3046e693)
It should exit on its own anyway and this will work even if the job has
already finished* (unlike kill).
[*] assuming job control is off, as it's the case when running the
test suite
Resolves: #39543
(cherry picked from commit 3849b0701a)
Before calling io.systemd.MachineImage.List.
The systemd-nspawn process takes a lock in the run() function in
nspawn.c and holds it for the entire runtime of that function. If we
call `machinectl terminate` the machine gets unregistered _before_ we
release the lock, so the original `machinectl status` check would return
early, allowing for a race where we call io.systemd.MachineImage.List
over Varlink when systemd-nspawn still holds the lock because the
process is still running.:
[ 41.691826] TEST-13-NSPAWN.sh[1102]: + machinectl terminate long-running
[ 41.695009] systemd-nspawn[2171]: Trying to halt container by sending TERM to container PID 1. Send SIGTERM again to trigger immediate termination.
[ 41.698235] systemd-machined[1192]: Machine long-running terminated.
[ 41.709520] TEST-13-NSPAWN.sh[1102]: + systemctl kill --signal=KILL systemd-nspawn@long-running.service
[ 41.709169] systemd-nspawn[2171]: Failed to unregister machine: No machine 'long-running' known
[ 41.720869] TEST-13-NSPAWN.sh[2346]: + varlinkctl --more call /run/systemd/machine/io.systemd.MachineImage io.systemd.MachineImage.List '{}'
[ 41.723359] TEST-13-NSPAWN.sh[2347]: + grep long-running
...
[ 41.735453] TEST-13-NSPAWN.sh[2352]: + varlinkctl call /run/systemd/machine/io.systemd.MachineImage io.systemd.MachineImage.List '{"name":"long-running", "acquireMetadata": "yes"}'
[ 41.736222] TEST-13-NSPAWN.sh[2353]: + grep OSRelease
[ 41.739500] TEST-13-NSPAWN.sh[2352]: Method call io.systemd.MachineImage.List() failed: Device or resource busy
[ 41.740641] systemd[1]: Received SIGCHLD.
[ 41.740670] systemd[1]: Child 2171 (systemd-nspawn) died (code=killed, status=9/KILL)
[ 41.740725] systemd[1]: systemd-nspawn@long-running.service: Child 2171 belongs to systemd-nspawn@long-running.service.
[ 41.740748] systemd[1]: systemd-nspawn@long-running.service: Main process exited, code=killed, status=9/KILL
[ 41.740755] systemd[1]: systemd-nspawn@long-running.service: Will spawn child (service_enter_stop_post): systemd-nspawn
[ 41.740872] systemd[1]: systemd-nspawn@long-running.service: About to execute: systemd-nspawn --cleanup --machine=long-running
...
Let's mitigate this by waiting until the corresponding
systemd-nspawn@.service instance enters the 'inactive' state where the
lock should be properly released.
Resolves: #39547
(cherry picked from commit ed4903660c)
Nowadays, the test script is run as a service, and no argument about
sanitizers are passed. Let's read them from the environment variables.
(cherry picked from commit da665b708a)
The process forked off by `systemd-notify --fork` is not a child of the
current shell, so using `wait` doesn't work. This then later causes a
race, when the test occasionally fails because it attempts to start a
new systemd-socket-activate instance before the old one is completely
gone:
[ 1488.947744] TEST-74-AUX-UTILS.sh[1938]: Child 1947 died with code 0
[ 1488.947952] TEST-74-AUX-UTILS.sh[1933]: + assert_eq hello hello
[ 1488.949716] TEST-74-AUX-UTILS.sh[1948]: + set +ex
[ 1488.950112] TEST-74-AUX-UTILS.sh[1950]: ++ cat /proc/1938/comm
[ 1488.945555] systemd[1]: Started systemd-networkd.service - Network Management.
[ 1488.950365] TEST-74-AUX-UTILS.sh[1933]: + assert_in systemd-socket systemd-socket-
[ 1488.950563] TEST-74-AUX-UTILS.sh[1951]: + set +ex
[ 1488.950766] TEST-74-AUX-UTILS.sh[1933]: + kill 1938
[ 1488.950766] TEST-74-AUX-UTILS.sh[1933]: + wait 1938
[ 1488.950766] TEST-74-AUX-UTILS.sh[1933]: .//usr/lib/systemd/tests/testdata/units/TEST-74-AUX-UTILS.socket-activate.sh: line 14: wait: pid 1938 is not a child of this shell
[ 1488.950766] TEST-74-AUX-UTILS.sh[1933]: + :
[ 1488.951486] TEST-74-AUX-UTILS.sh[1952]: ++ systemd-notify --fork -- systemd-socket-activate -l 1234 --now socat ACCEPT-FD:3 PIPE
[ 1488.952222] TEST-74-AUX-UTILS.sh[1953]: Failed to listen on [::]🔢 Address already in use
[ 1488.952222] TEST-74-AUX-UTILS.sh[1953]: Failed to open '1234': Address already in use
[ 1488.956831] TEST-74-AUX-UTILS.sh[1933]: + PID=1953
[ 1488.957078] TEST-74-AUX-UTILS.sh[102]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/TEST-74-AUX-UTILS.socket-activate.sh failed'
[ 1488.957078] TEST-74-AUX-UTILS.sh[102]: Subtest /usr/lib/systemd/tests/testdata/units/TEST-74-AUX-UTILS.socket-activate.sh failed
(cherry picked from commit c05758663b)
Fixes the following warning:
TEST-75-RESOLVED.sh[2251]: ++ restart_resolved
TEST-75-RESOLVED.sh[2251]: ++ systemctl stop systemd-resolved.service
TEST-75-RESOLVED.sh[2271]: Stopping 'systemd-resolved.service', but its triggering units are still active:
TEST-75-RESOLVED.sh[2271]: systemd-resolved-monitor.socket, systemd-resolved-varlink.socket
(cherry picked from commit f88f0271f8)
It looks like the 4 second sleep might not be enough on some slower
machines (like the ARM GH Actions nodes) which can lead to the DS RRs
propagation to clash with the manual test zone edit, and the
signed.test zone then might end up not properly signed:
TEST-75-RESOLVED.sh[749]: + : '--- ZONE: signed.test (static DNSSEC) ---'
TEST-75-RESOLVED.sh[749]: + run_delv @ns1.unsigned.test signed.test
TEST-75-RESOLVED.sh[749]: + run delv -a /etc/bind.keys @ns1.unsigned.test signed.test
TEST-75-RESOLVED.sh[778]: + delv -a /etc/bind.keys @ns1.unsigned.test signed.test
TEST-75-RESOLVED.sh[779]: + tee /tmp/tmp.2KOIiyrgth
TEST-75-RESOLVED.sh[779]: ;; /etc/bind.keys:1: option 'managed-keys' is deprecated
TEST-75-RESOLVED.sh[779]: ;; validating signed.test/DS: no valid signature found
TEST-75-RESOLVED.sh[779]: ;; validating signed.test/A: no valid signature found
TEST-75-RESOLVED.sh[779]: ; unsigned answer
TEST-75-RESOLVED.sh[779]: signed.test. 86400 IN A 10.0.0.10
TEST-75-RESOLVED.sh[779]: signed.test. 86400 IN RRSIG A 13 2 86400 20251028114356 20251014101356 39330 signed.test. oo3ca8WPusbBPRhzsEKw3bsBBqFtI8i4bckoMVNzt7lY+udGW6PlaSYj OjpQGgY9oglowVM9bteNtwJKHUbvtw==
TEST-75-RESOLVED.sh[749]: + grep -qF '; fully validated' /tmp/tmp.2KOIiyrgth
[FAILED] Failed to start TEST-75-RESOLVED.service - TEST-75-RESOLVED.
Let's explicitly wait for the DS records propagation to finish before we
start editing the test zone to avoid this.
I'm still not completely sure if this is the root cause, but it's the
best shot I currently have, so I'll let the CIs decide.
(cherry picked from commit 92631f1962)
Both sysext and confext used the host's /etc/initrd-release file even
when --root=/somewhere was specified. A workaround was the
SYSTEMD_IN_INITRD= env var but without knowing this it was quite
confusing. Aside from users validating their extensions, the primary
use case for this to matter is when the extensions are set up from the
initrd where the initrd-release file is present when running but we want
to prepare the extensions for the final system and thus should match
for the right scope.
Make systemd-sysext check for /etc/initrd-release inside the given
--root= tree. An alternative would be to always ignore the
initrd-release check when --root= is passed but this way it is more
consistent. The image policy logic for EFI-loader-passed extensions
won't take effect when --root= is used, though.
(cherry picked from commit 570eae5007)
The last sysext test leaked things into new tests added later,
uncovered by any new tests leftover check.
Remove the mutable folder state through a trap as done in other tests.
(cherry picked from commit 6649562924)
Before:
Next elapse timestamp should be Sun Oct 12 00:10:00 UTC 2025 <= Sun 2025-10-12 05:43:04 UTC <= Sun Oct 12 22:10:00 UTC
After:
Next elapse timestamp should be Tue 2025-10-14 00:10:00 CEST <= Tue 2025-10-14 19:39:11 CEST <= Tue 2025-10-14 22:10:00 CEST
(cherry picked from commit 62ca845ac7)
Before 23ac08115a, even if we failed to
create the cgroup for a unit, a cgroup runtime object for the cgroup is
created with the cgroup path. Hence, the creation of cgroup is failed,
execution of the unit will fail in posix_spawn_wrapper() and logged
something like the following:
```
systemd[1]: testservice.service: Failed to create cgroup /testslice.slice/testservice.service: Cannot allocate memory
systemd[1]: testservice.service: Failed to spawn executor: No such file or directory
systemd[1]: testservice.service: Failed to spawn 'start' task: No such file or directory
systemd[1]: testservice.service: Failed with result 'resources'.
systemd[1]: Failed to start testservice.service.
```
However, after the commit, when we failed to create the cgroup, a cgroup
runtime object is not created, hence NULL will be assigned to
ExecParameters.cgroup_path in unit_set_exec_params().
Hence, the unit process will be invoked in the init.scope.
```
systemd[1]: testservice.service: Failed to create cgroup /testslice.slice/testservice.service: Cannot allocate memory
systemd[1]: Starting testservice.service...
cat[1094]: 0::/init.scope
systemd[1]: testservice.service: Deactivated successfully.
systemd[1]: Finished testservice.service.
```
where the test service calls 'cat /proc/self/cgroup'.
To fix the issue, let's fail earlier when we failed to create cgroup.
Follow-up for 23ac08115a (v258).
(cherry picked from commit 8b4ee3d68d)
