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
Both `list` and `status` with `--json=pretty|short` show the description.
It is fetched via D-Bus by org.freedesktop.network1.Manager.Describe
This change exposes the same data via Varlink API `io.systemd.Network.Describe`
and migrates networkctl list and status commands to use Varlink API.
Update GetStates IDL to use enums for link states.
Let's do the check early and skip most of the file if appropriate. Also, treat
missing $TERM same as "dumb". We're almost certainly at a dump terminal in that
case.
Load modules in parallel using a pool of worker threads. The number of
threads is equal to the number of CPUs, with a maximum of 16 (to avoid
too many threads being started during boot on systems with many an high
core count, since the number of modules loaded on boot is usually on
the small side).
The number of threads can optionally be specified manually using the
SYSTEMD_MODULES_LOAD_NUM_THREADS environment variable; in this case,
no limit is enforced. If SYSTEMD_MODULES_LOAD_NUM_THREADS is set to 0,
probing happens sequentially.
Co-authored-by: Eric Curtin <ecurtin@redhat.com>
