In aad0d11e7c we stopped supporting XBOOTLDR
with a different fs driver. This was the primary example that comes to mind
when we talk about loading filesystem drivers in the firmware. Since we don't
want people to do load such drivers, use a different example.
We said in the header that "all EFI variables use the vendor UUID
4a67b082-0a4c-41cf-b6c7-440b29bb8c4f", but people not familiar with
UEFI might not know that this is concatenated with the variable name.
Let's use the full form once — when introducing the variable — to
make it easier to grep and search for.
While at it, use sembreaks in the document. This makes subsequent
changes much easier to review. (It also shows that some sentences
are rather long and thus hard to understand.)
On OOM event, oomd tries to kill a cgroup until it succeedes.
The kill can fail with EPERM in case a pid is not killed, this leaves
the cgroup with only half of the processed killed.
This is unlikely but theoretically possible in a user namespace,
where systemd run as root inside the container and tries to kill a
cgroup with some PID from the host namespace.
To address this, send the SIG0 signal to all the processes to check
that we have privileges to kill them.
Create and use new function pam_debug_syslog_errno() instead to ensure the
message only appears when debug mode is enabled. Pass the debug flag to
open_osc_context() and close_osc_context() to support this change.
The function accepts a level parameter but was always logging at
LOG_ERR. Fix by passing the level parameter to sym_pam_vsyslog()
instead of hardcoding LOG_ERR.
This caused debug and warning messages to incorrectly appear in error
logs.
Make “effect” plural to indicate that BindsTo= also includes the other effects
of Requires= (like starting the listed units).
The documentation of Requires= already describes that the configuring unit is
stopped/restarted if any of the list units is explicitly stopped/restarted.
This made the previous wording “in addition to the effect of Requires, it
declares that if the unit bound to is stopped, this unit will be stopped too.”
ambiguous – this is no in addition, Requires= already does that, at least for
some (namely the explicit) cases.
Resolve this by making it clear what the actual difference to Requires= is and
further mention that this also includes failed units.
Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
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
Currently, when a socket unit specifies SmackLabel=,
the label is not applied to the underlying Unix socket file or its file
descriptor.
This change ensures that the SMACK label is applied both to the
Unix socket path on the filesystem and to all associated socket FDs
when the socket is created.
Testing:
- Tested on Fedora 43 with kernel 6.17.7 with SMACK enabled.
- Created a systemd socket unit:
[Unit]
Description=UNIX socket
[Socket]
ListenStream=/run/test.sock
SmackLabel=label
[Install]
WantedBy=sockets.target
- Created a corresponding service:
[Unit]
Description=UNIX socket service
Requires=test.socket
[Service]
ExecStart=/usr/bin/socat -v - -
StandardInput=socket
[Install]
WantedBy=multi-user.target
- Verified SMACK labels using getfattr:
- Without SmackLabel:
```
# file: run/test.sock
security.SMACK64="_"
# file: proc/<pid>/fd/*
security.SMACK64="*"
```
- With SmackLabel=label:
```
# file: run/test.sock
security.SMACK64="label"
# file: proc/<pid>/fd/*
security.SMACK64="label"
```
In all cases, everything that we list in 'extract', we also list in
'sources'. We can simplify things by automatically appending the first
list to the second.
In the listings, move 'extract' key right below 'sources', since now
they are both "sources", just with slightly different meanings.
When a socket unit specifies SmackLabel=, the label was previously
not applied to the underlying Unix socket file or its file descriptor.
This change ensures that the SMACK label is applied both to the
socket path on the filesystem and to the opened socket FD.
The function socket_address_listen() is declared at shared/socket-label.c,
however its prototype was in basic/socket-util.h. This moves the
prototype to shared/socket-label.h.
Also, enum SocketAddressBindIPv6Only is not used anymore in basic/*.[ch].
Let's move the definition and its string table to shared/socket-label.[ch].
Follow-up for b25a930f0e.
When inheriting file descriptors for stdout/stderr (either from stdin or
when making stderr inherit from stdout), we previously just assumed they
would be writable and dup'd them. This could lead to broken setups if
the inherited FD was actually opened read-only.
Before dup'ing any inherited FDs to stdout/stderr, verify they are
actually writable using the new fd_is_writable() helper. If not, fall
back to /dev/null (or reopen the terminal in the TTY case) with a
warning, rather than silently creating a broken setup where output
operations would fail.
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.
Looking at the list, "test" or "testing" seems to be a fairly generic entry
that is missing from the list of suggestions. I went with "testing" because it
fits better with the other item, e.g. "staging".
In https://github.com/systemd/systemd/issues/38743 "laboratory" was also
suggested. I didn't include this because that is more about the location, not
deployment type. Any of the other deployments could be in a "laboratory".
Closes https://github.com/systemd/systemd/issues/38743.
This series fixes two distinct, pretty bad bugs in `ASSERT_SIGNAL`.
These bugs can allow failing tests to pass, and can also cause the test
runner to silently terminate prematurely in a way that looks like
success.
This is not theoretical, see
https://github.com/systemd/systemd/pull/39674#discussion_r2540552699 for
a real case of this happening.
---
Bug 1: Parent process hallucinates it is the child and re-executes the
expression being tested
Previously, assert_signal_internal() returned 0 in two mutually
exclusive states:
1. We are the child process (immediately after fork()).
2. We are the parent process, and the child exited normally (status 0).
The macro failed to distinguish these cases. If a child failed to crash
as expected, the parent received 0, incorrectly interpreted it as it
being the child, and re-executed the test expression inside the parent
process.
This can cause tests to falsely pass. The parent would successfully run
the expression (which wasn't supposed to crash in the parent), succeed,
and call _exit(EXIT_SUCCESS).
The second consequence is silent truncation. When the parent called
_exit(), it terminated the entire test runner immediately. Any
subsequent tests in the same binary were never executed.
---
Bug 2: Conflation of exit codes and signals
The harness returned the raw si_status without checking si_code. This
meant that an exit code was indistinguishable from a signal number. For
example, if a child process failed and called exit(6), the harness
reported it as having been killed by SIGABRT (signal 6).
---
This PR both fixes the bugs and reworks the ASSERT_SIGNAL infrastructure
to ensure this is very unlikely to regress:
- assert_signal_internal now returns an explicit control flow enum
(FORK_CHILD / FORK_PARENT) separate from the status data. This makes it
structurally impossible for the parent to hallucinate that it is the
child.
- The output parameter is only populated with a signal number if si_code
confirms the process was killed by a signal. Normal exits return 0.
assert_signal_internal() returns 0 in two distinct cases:
1. In the child process (immediately after fork returns 0).
2. In the parent process, if the child exited normally (no signal).
ASSERT_SIGNAL fails to distinguish these cases. When a child exited
normally (case 2), the parent process receives 0, incorrectly interprets
it as meaning it is the child, and re-executes the test expression
inside the parent process. Goodness gracious!
This causes two severe test integrity issues:
1. False positives. The parent can run the expression, succeed, and call
_exit(EXIT_SUCCESS), causing the test to pass even though no signal
was raised.
2. Silent truncation. The _exit() call in the parent terminates the test
runner prematurely, preventing subsequent tests in the same file from
running.
Example of the bug in action, from #39674:
ASSERT_SIGNAL(fd_is_writable(closed_fd), SIGABRT)
This test should fail (fd_is_writable does not SIGABRT here), but with
the bug, the parent hallucinated being the child, re-ran the expression
successfully, and exited with success.
Fix this by refactoring assert_signal_internal() to be much more strict
about separating control flow from data.
The signal status is now returned via a strictly typed output parameter,
guaranteeing that determining whether we are the child is never
conflated with whether the child exited cleanly.
ASAN installs signal handlers to catch crashes like SIGSEGV or SIGILL.
When these signals are raised, ASAN traps them, prints an error report,
and then typically terminates the process with a different signal (often
SIGABRT) or a non-zero exit code.
This interferes with ASSERT_SIGNAL when checking for specific crash
signals (for example, checking that a function raises SIGSEGV). In such
a case, the test harness sees the ASAN termination signal rather than
the expected signal, causing the test to fail.
Fix this by resetting the signal handler to SIG_DFL in the child process
immediately before executing the test expression. This ensures the
kernel kills the process directly with the expected signal, bypassing
ASAN's interceptors.
When a child process exits normally (si_code == CLD_EXITED),
siginfo.si_status contains the exit code. When it is killed by a signal
(si_code == CLD_KILLED or CLD_DUMPED), si_status contains the signal
number. However, assert_signal_internal() returns si_status blindly.
This causes exit codes to be misinterpreted as signal numbers.
This allows failing tests to silently pass if their exit code
numerically coincides with the expected signal. For example, a test
expecting SIGABRT (6) would incorrectly pass if the child simply exited
with status 6 instead of being killed by a signal.
Fix this by checking si_code. Only return si_status as a signal number
if the child was actually killed by a signal (CLD_KILLED or CLD_DUMPED).
If the child exited normally (CLD_EXITED), return 0 to indicate that no
signal occurred.
When inheriting file descriptors for stdout/stderr (either from stdin
or when making stderr inherit from stdout), we previously just assumed
they would be writable and dup'd them. This could lead to broken setups
if the inherited FD was actually opened read-only.
Before dup'ing any inherited FDs to stdout/stderr, verify they are
actually writable using the new fd_is_writable() helper. If not, fall
back to /dev/null (or reopen the terminal in the TTY case) with a
warning, rather than silently creating a broken setup where output
operations would fail.
This checks whether a file descriptor is valid and opened in a mode that
allows writing (O_WRONLY or O_RDWR). This is useful when we want to
verify that inherited FDs can actually be used for output operations
before dup'ing them.
The helper explicitly handles O_PATH file descriptors, which cannot be
used for I/O operations and thus are never writable.
We were getting a list of invocation IDs, picking one at random,
and then querying the unit. This is obviously racy.
TEST-74-AUX-UTILS.sh[2873]: + varlinkctl call /run/systemd/io.systemd.Manager io.systemd.Unit.List
'{"invocationID": "2052c9a5-7983-4f72-9910-c49e38c91dab"}'
TEST-74-AUX-UTILS.sh[3707]: Method call io.systemd.Unit.List() failed: io.systemd.Unit.NoSuchUnit
The complicated varlink + jq callout is replaced by a simple systemctl call.
I think that's better to avoid a complicated jq expression.
Fixes https://github.com/systemd/systemd/issues/38647.
The ASSERT_SIGNAL macro uses a fixed variable name, `_r`. This prevents
nesting the macro (like ASSERT_SIGNAL(ASSERT_SIGNAL(...))), as the inner
instance would shadow the outer instance's variable.
Switch to using the UNIQ_T helper to generate unique variable names at
each expansion level. This allows the macro to be used recursively,
which is required for upcoming regression tests regarding signal
handling logic.
Symbols exported by libshared can't get pruned by the linker, so
every unused exported symbol is effectively dead code we ship to users
for no good reason. Let's add a script to analyze how many such symbols
we have.
We also add a meson test to run the script on all of our binaries.
Since it detects unused symbols and still has a few false positives,
don't enable the test by default similar to the clang-tidy tests.
The script was 100% vibe coded by Github Copilot with Claude Sonnet 4.5
as the model.
Current results are (without the unused symbols list):
Analysis of libsystemd-shared-259.so
======================================================================
Total exported symbols: 4830
(excluding public API symbols starting with 'sd_')
Used symbols: 4672
Unused symbols: 158
Usage rate: 96.7%
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Matteo Croce
Daan De Meyer
Christoph Anton Mitterer
Mike Yuan
Yu Watanabe
Lennart Poettering
val4oss
Frantisek Sumsal
Marc-Antoine Riou
Quentin Deslandes
Chris Down
Martin Hundebøll