Closes#35788
This gives access to credentials within ExecCondition=. As described in
ticket #35788, I do have a use-case for this and as noted in the
commit that dropped this[1], this is OK to be revisited if there are
use-cases.
[1] a145623bc4
systemd-repart is incorrectly choosing the loop-mount
code path to copy files after formatting, instead of using the --rootdir
path, which is required by mkfs.btrfs to apply compression (since it's
on files, not the fs).
So two fixes (and an integ test):
1. If Btrfs compression is requested without a root directory (e.g.,
Compression= without CopyFiles=), we now log a warning and skip the
--compress flag. This prevents the mkfs.btrfs failure, and it's
meaningless anyway without any files.
2. The logic in repart now uses the --rootdir code path whenever the
partition is btrfs and compression is requested. Otherwise it still
won't work even in the legitimate case because use the loop mounting
code, which is too late to use --compress.
Fixes: https://github.com/systemd/systemd/issues/39584
Add testcase_btrfs_compression() to verify that btrfs partitions with
Compression= and CopyFiles= directives work correctly.
The test verifies the fix for issue #39584, where mkfs.btrfs would fail
with "ERROR: --compression must be used with --rootdir" when repart
tried to create compressed btrfs filesystems.
The test creates a partition definition with Format=btrfs,
Compression=zstd, and CopyFiles=, then validates:
1. systemd-repart output shows "Rootdir from:" and "Compress:",
confirming that the --rootdir code path is used
2. mkfs.btrfs is invoked with both --compress and --rootdir options
3. The file is successfully copied to the filesystem
4. Compression is actually applied (verified via compsize output
containing "zstd")
- use loop for checking existence of functions,
- rename HAVE_LIBARCHIVE_XYZ -> HAVE_ARCHIVE_XYZ to make them match with
the function name,
- do not conditionally include user-util.h in libarchive-util.h,
- sort library function symbols.
When generating a name for a transient userns automatically we so far
just included our PID to make it unique. That doens't really work if
multiple userns shall be kept in parallel by a single process. Let's hence
include a counter as well.
This seems to be a mistake, in place since the first commit: we only
want the downloaded data in memory if this is a sha256sums or gpg file,
which we need to prorcess ourselves.
Instead of authenticating the downloaded image explicity in the tar and
in the raw downloader, we can now rely on the checksum checking in the
generic PullJob code. Hence do so: drop tep the checksum field from
TarPull and RawPull, and just initialized the ->expected_checksum in the
relevant PullJob instead.
We generally want to store data in parsed form, not formatted form,
hence let's follow our own rules on this, and store the message digest
as "struct iovec" rather than as string. This is generally more
efficient and safer, simply because of case issues.
Just as a safety measure, let's always NUL terminate what we are
downloading, maybe future code will parse it as string, and is sloppy by
accident.
(We have similar logic in read_full_file(), and I think it's a really
good rule, to always implicitly NUL terminate blobs we acquire that
might very well be used as text later on)
Follow-up for 379d9ae222
After the commit, the functions are only used to determine
whether journals shall be forwarded to selected targets,
hence rename as such and remove effectively unused condition
on EXEC_OUTPUT_TTY.
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
Fixes#38486 again, which was fixed by
1405d46bf9, but regressed again by
f875a8026e.
This also make it use exec_input_is_terminal().
Follow-up for f875a8026e.
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