For safety, prefer board product name, that always has the short name,
over system product name, that in few models has a very long string with
the short name at the end.
The following models added at the time of this commit BR1100FKA, RC72LA
and TP412UA needs a wildcard before when using pn.
Unmerged Q502LAB, Q551LB and Q551LN, in the merged match there are many
more unreported models.
Chris Down [Tue, 17 Feb 2026 06:58:44 +0000 (14:58 +0800)]
oomd: Fix unnecessary delays during OOM kills with pending kills present
Let's say a user has two services with ManagedOOMMemoryPressure=kill,
perhaps a web server under system.slice and a batch job under
user.slice. Both exceed their pressure limits. On the previous timer
tick, oomd has already queued the web server's candidate for killing,
but the prekill hook has not yet responded, so the kill is still
pending.
In the code, monitor_memory_pressure_contexts_handler() iterates over
all pressure targets that have exceeded their limits. When it reaches
the web server target and calls oomd_cgroup_kill_mark(), which returns 0
because that cgroup is already queued. The code treats this the same as
a successful new kill: it resets the 15 second delay timer and returns
from the function, exiting the loop.
This loop is handled by SET_FOREACH and the iteration order is
hash-dependent. As such, if the web server target happens coincidentally
to be visited first, oomd never evaluates the batch job target at all.
The effect is twofold:
1. oomd stalls for 15 seconds despite not having initiated any new kill.
That can unnecessarily delay further action to stem increases in
memory pressure. The delay exists to let stale pressure counters
settle after a kill, but no kill has happened here.
2. It non-deterministically skips pressure targets that may have
unqueued candidates, dangerously allowing memory pressure to persist
for longer than it should.
Fix this by skipping cgroups that are already queued so the loop
proceeds to try other pressure targets. We should only delay when a new
kill mark is actually created.
Chris Down [Tue, 17 Feb 2026 06:30:16 +0000 (14:30 +0800)]
oomd: Fix silent failure to find bad cgroups when another cgroup dies
Consider a workload slice with several sibling cgroups. Imagine that one
of those cgroups is removed between the moment oomd enumerates the
directory and the moment it reads memory.oom.group. This is actually
relatively plausible under the high memory pressure conditions where
oomd is most needed.
In this case, the failed read prompts us to `return 0`, which exits the
entire enumeration loop in recursively_get_cgroup_context(). As a
result, all remaining sibling cgroups are silently dropped from the
candidate list for that monitoring cycle.
The effect is that oomd can fail to identify and kill the actual
offending cgroup, allowing memory pressure to persist until a subsequent
cycle where the race doesn't occur.
Fix this by instead proceeding to evaluate further sibling cgroups.
Let's say a user has two services with ManagedOOMMemoryPressure=kill,
one for a web server under system.slice, and one for a batch job under
user.slice. The batch job is causing severe memory pressure, whereas the
web server's cgroup has no processes with significant pgscan activity.
In the code, monitor_memory_pressure_contexts_handler() iterates over
all pressure targets that have exceeded their limits. When
oomd_select_by_pgscan_rate() returns 0 (that is, no candidates) for a
target, we return from the entire SET_FOREACH loop instead of moving to
the next target. Since SET_FOREACH iteration order is hash-dependent, if
the web server target happens to be visited first, oomd will find no
kill candidates for it and exit the loop. The batch job target that is
actually slamming the machine will never even be evaluated, and can
continue to wreak havoc without any intervention.
The effect is that oomd non-deterministically and silently fails to kill
cgroups that it should actually kill, allowing memory pressure to
persist and dangerously build up on the machine.
The fix is simple, keep evaluating remaining targets when one does not
match.
These were introduced as part of the effort of sd-executor
worker pool (#29566), which never landed due to unsignificant
performance improvement. Let's just remove the unused
helpers. If that work ever gets resurrected they can be
restored from this commit pretty easily.
Yu Watanabe [Tue, 17 Feb 2026 05:53:46 +0000 (14:53 +0900)]
oomd: Fix Killed signal reason being lost (#40689)
Emitting "oom" doesn't mesh with the org.freedesktop.oom1.Manager
Killed() API contract, which defines "memory-used" and "memory-pressure"
as possible reasons. Consumers that key off reason thus will either lose
policy attribution or may reject the unknown value completely.
Plumb the reason through so it is visible to consumers.
Chris Down [Sun, 15 Feb 2026 17:42:51 +0000 (01:42 +0800)]
oomd: Fix Killed signal reason being lost
Emitting "oom" doesn't mesh with the org.freedesktop.oom1.Manager
Killed() API contract, which defines "memory-used" and "memory-pressure"
as possible reasons. Consumers that key off reason thus will either lose
policy attribution or may reject the unknown value completely.
Plumb the reason through so it is visible to consumers.
Daan De Meyer [Mon, 16 Feb 2026 18:59:10 +0000 (19:59 +0100)]
nspawn-mount: Use setns() in wipe_fully_visible_api_fs()
namespace_enter() now does a is_our_namespace() check, which requires
/proc on older kernels, which is not available anymore after we call
do_wipe_fully_visible_api_fs() in wipe_fully_visible_api_fs().
Let's just call setns() instead as namespace_enter() is overkill to
enter a single namespace anyway.
Daan De Meyer [Mon, 16 Feb 2026 14:42:35 +0000 (15:42 +0100)]
mkosi: Set CacheOnly=metadata for test images (#40699)
The default behavior is to sync repository metadata for every image
that does not have a cache and we recently changed behavior to
invalidate
all cached images whenever we decide the repository metadata needs to
be resynced.
In systemd we have two images that are not cached because they use
BaseTrees=
hence set CacheOnly=metadata to explicitly indicate these two images
should never cause a repository metadata if resync even though they are
not cached.
Daan De Meyer [Mon, 16 Feb 2026 12:28:22 +0000 (13:28 +0100)]
mkosi: Set CacheOnly=metadata for test images
The default behavior is to sync repository metadata for every image
that does not have a cache and we recently changed behavior to invalidate
all cached images whenever we decide the repository metadata needs to
be resynced.
In systemd we have two images that are not cached because they use BaseTrees=
hence set CacheOnly=metadata to explicitly indicate these two images
should never cause a repository metadata if resync even though they are
not cached.
* 66d51024b7 man: Update caching section
* 4eac60f168 Remove all cached images if repository metadata will be synced
* 025c6c0150 Move Incremental= to inherited settings in docs
* 427970d8fd Make MakeScriptsExecutable= a multiversal setting
* 53bd2da6fe Look at all CacheOnly= settings to determine if we need to sync metadata
* 114ae558ef config / qemu: add Console=headless
Daan De Meyer [Mon, 16 Feb 2026 10:26:41 +0000 (11:26 +0100)]
namespace-util: Merge namespace_enter_delegated() into namespace_enter() (#40669)
There's no need to pass in a boolean to decide whether we use
namespace_enter_delegated() or not. Instead, we can just check if we
have CAP_SYS_ADMIN in our own user namespace. If we don't, then we have
to insist on a child user namespace being passed in and we have to enter
it first to get CAP_SYS_ADMIN as without CAP_SYS_ADMIN we wouldn't be
able
to call setns() in the first place. If we do have CAP_SYS_ADMIN, we can
always enter the other namespaces first before entering the user
namespace.
Additionally, we don't fail anymore if we can't reset the UID/GID since
a
root user might not always be available in every user namespace we might
enter.
r-vdp [Thu, 12 Feb 2026 21:52:54 +0000 (23:52 +0200)]
dns-delegates: add support for setting a firewall mark
This makes it possible to have DNS requests for certain domains routed
differently than normal requests, which is for instance useful when
using policy routing to route traffic over a VPN but DNS requests for
the VPN endpoint itself, should be routed differently.
It doesn't make much sense to configure a firewall mark at the level of
a network interface, but at the level of a DNS delegate it can be very
useful.
Daan De Meyer [Sun, 15 Feb 2026 13:22:44 +0000 (14:22 +0100)]
namespace-util: Merge namespace_enter_delegated() into namespace_enter()
There's no need to pass in a boolean to decide whether we use
namespace_enter_delegated() or not. Instead, we can just check if we
have CAP_SYS_ADMIN in our own user namespace. If we don't, then we have
to insist on a child user namespace being passed in and we have to enter
it first to get CAP_SYS_ADMIN as without CAP_SYS_ADMIN we wouldn't be able
to call setns() in the first place. If we do have CAP_SYS_ADMIN, we can
always enter the other namespaces first before entering the user namespace.
Additionally, we don't fail anymore if we can't reset the UID/GID since a
root user might not always be available in every user namespace we might
enter.
Bash does not provide an easy way to discern if an exit status came from
a signal, or was a legitimate non-zero exit (i.e. a failure). It can be
done, by using job control or by invoking another program; however, such
approaches require modifying the command entered by a user and are, thus,
invasive and risky.
Since an exit status of 129 on a command could either indicate it exited
cleanly with `exit(129)` or was interrupted by `SIGHUP`, the osc context
should report both possibilities, to acknowledge our uncertainty. Given
we have no idea what happened, besides an unsuccessful exit, the exit is
described as `exit=failure`.
Moreover, discerning between an `interrupt` and a `crash` with a command
likely involves categorizing every signal. It is fairly obvious `SIGINT`
is an interrupt and also obvious, IMO, that `SIGSEGV` is a crash. Avoid
the complication (and potential disagreements) by using the encompassing,
generic value — one that remains true if no signal occurred.
Chris Lindee [Mon, 16 Feb 2026 06:08:31 +0000 (00:08 -0600)]
profile/systemd-osc-context: Bring exit up to spec
The exit status should be compared against 128 — not 127 — as the Bash
manual, under the EXIT STATUS section, states [0]:
When a command terminates on a fatal signal N, bash uses the value
of 128+N as the exit status.
If a command is not found, the child process created to execute it
returns a status of 127. If a command is found but is not
executable, the return status is 126.
Furthermore, UAPI.15 specifies the `signal` value must be the symbolic
signal name, not a numerical value [1]. Luckily, POSIX.1-2008 ensures
the shell must supply `kill -l`, which must be able to convert `$?` to
the signal that could cause such an exit in that shell [2]. It should
be noted that only a select handful of signals have a standard numeric
value; all others are implementation-defined [3]. This is why UAPI.15
requires the symbolic name, as the value may differ across systems.
Notably, not every value above 128 needs to correspond to a signal; on
my Linux system, only exit codes 129–192 indicate a signal. Again, we
can use `kill -l`, which will exit non-zero when an exit code does not
come from a signal (plus 128) [4].
Signal 0 (which would correspond to exit code 128) is reserved for the
null signal, per POSIX.1-2008 [5], and therefore will never be an exit
signal.
This change brings the implementation into compliance.
The commit introduced a new "metrics" varlink server, but for
user scope stuff it is not bound anywhere. The copy-pasted
"fresh" handling for deserialization is also essentially
meaningless as metrics_setup_varlink_server() doesn't even report
whether the varlink server is fresh (let alone that no serialization
is being done at all right now). Moreover, currently the event
priority is hardcoded, while event loop and associated priority
assignment ought to be subject to each daemon.
While fixing the mentioned issues I took the chance to restructure
the existing code a bit for readability. Note that serialization
for the metrics server is still missing - it will be tackled
in subsequent commits.
Mike Yuan [Sun, 8 Feb 2026 20:47:38 +0000 (21:47 +0100)]
tree-wide: drop redundant check for SD_VARLINK_METHOD_MORE flag
If the IDL declares the method requires 'more' yet the call doesn't
have it set, varlink_idl_validate_method_call() should have rejected
it and the callback shouldn't be reached.
Daan De Meyer [Fri, 13 Feb 2026 11:24:49 +0000 (12:24 +0100)]
user-util: Don't setgroups() if /proc/self/gid_map is empty
If /proc/self/gid_map is empty, the kernel will refuse setgroups(),
so don't attempt it if that's the case on top of the /proc/self/setgroups
check we already have.
projects / thirdparty / systemd.git / log
