test-shift-uid.c doesn't actually use anything from libacl. It all goes
through shared/, and the dep there is enough.
Same for the coredump stuffi, logind and core/.
And pstore doesn't use it at all, neither directly or indirectly.
Expose variables for system-alloc-uid-min and system-alloc-gid-min
similar to the UID/GID ranges already exposed for the respective
maximums, and other UID/GID ranges.
This fixes two things: first of all it ensures we take the override
status output field properly into account, instead of going directly to
the regular one.
Moreover, it ensures that we bypass auto for both notice + emergency,
since both have the same "impact", and, don't limit this for notice
only.
For managed oom kills, we check the user.oomd_ooms property which
reports how many times systemd-oomd recursively killed the entire
cgroup. For kernel OOM kills, we check the oom_kill property from
memory.events which reports how many processes were killed by the
kernel OOM killer in the corresponding cgroup and its child cgroups.
For units with Delegate=yes, this is problematic, becase OOM kills
in child cgroups that were handled by the delegated unit will still
be treated as unit OOM kills by systemd.
Specifically, if systemd is managing the delegated cgroup and
memory.oom.group=1 is set on both the service cgroup and the child
cgroup, if the child cgroup is OOM killed and this is handled by systemd
running inside the delegated units, when the unit exits later, it will
still be treated as oom-killed because oom_kill in memory.events will
contain the OOM kills that happened in the child cgroup.
To allow addressing this, the oom_group_kill property was added to the
memory.events and memory.events.local files which allows reading how many
times the entire cgroup was oom killed by the kernel if memory.oom.group=1.
If we read this from memory.events.local, we know how many times the unit's
entire cgroup (plus child cgroups) got oom killed by the kernel. This matches
what we report for systemd-oomd managed oom kills and avoids reporting the
unit as oom-killed if a child cgroup was oom killed by the kernel due to
having memory.oom.group=1 set on it.
Since this is only available from kernel 5.12 onwards, we fall back to
reading the oom_kill field from memory.events if the oom_group_kill property
is not available.
This removes iptables/libiptc backend support in firewall-util, as
already announced by 5c68c51045.
Then, this drops meaningless `FirewallContext` wrapper.
let's skip over credentials we cannot decode when they are found with
ImportCredential=. When installing an OS on some disk and using that
disk on a different machine than assumed we'll otherwise end up with a
broken boot, because the credentials cannot be decoded when starting
systemd-firstboot. Let's handle this somewhat gracefully.
This leaves handling for LoadCredential=/SetCredential= as it is (i.e.
failure to decrypt results in service failure), because it is a lot more
explicit and focussed as opposed to ImportCredentials= which looks
everywhere, uses globs and so on and is hence very vague and unfocussed.
Fixes: #34740
The function searches the list, and it potentially takes O(n).
Let's cache the result and avoid duplicated calls.
This also rebreaks comments, and rewrites conditions in an equivalent
form that is easy to read and matches with the comment above.
No functional change, just refactoring.
Enhance CPU time logging to include wall clock duration alongside
CPU consumption. When a unit transitions to inactive/failed state,
the log message now shows both CPU time consumed and the total wall
clock time since activation.
Changes:
- Calculate wall clock duration using active_enter_timestamp
- Update log format: "Consumed Xs CPU time over Ys wall clock time"
- Fallback to original format if no activation timestamp available
- Use monotonic clock for accurate duration calculation
This addresses issue #35738 by providing administrators better context
about service performance and resource efficiency.
Example output:
- With wall clock: "service: Consumed 30s CPU time over 5min wall clock time"
- Without timestamp: "service: Consumed 30s CPU time"
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
Fixes the following varlink IDL validation error:
```
systemd-oomd[1687]: varlink-11-11: Parameters for method io.systemd.oom.ReportManagedOOMCGroups()
didn't pass validation on field 'cgroups': No anode
```
Follow-ups for 23ac08115a.
Since the commit, the cgroup path is set only when it is realized.
Fixes the following varlink IDL validation failure:
```
systemd-oomd[1687]: Varlink-IDL: Mandatory field 'path' is null or missing on object, refusing.
```
Otherwise, ExecXYZ= given by drop-ins may be added to a masked unit,
then commands may be unexpectedly executed. For example, if an ExecStop=
is set in a drop-in for a running unit, then 'systemctl mask --now' for
the unit try to invoke the command specified in ExecStop=.
Fixes#38802.
As you can see, something spurious happens in the logs below.
```
initrd-switch-root.target: Trying to enqueue job initrd-switch-root.target/start/isolate
systemd-repart.service: Looking at job systemd-repart.service/stop conflicted_by=no
systemd-repart.service: Looking at job systemd-repart.service/start conflicted_by=no
systemd-repart.service: Fixing conflicting jobs systemd-repart.service/stop,systemd-repart.service/start by deleting job systemd-repart.service/stop
initrd-switch-root.target: Fixing conflicting jobs initrd-switch-root.target/stop,initrd-switch-root.target/start by deleting job initrd-switch-root.target/stop
systemd-repart.service: Deleting job systemd-repart.service/start as dependency of job initrd-switch-root.target/stop
```
The two conflicting jobs for systemd-repart.service are initially queued
as the following:
- initrd-switch-root.target has Wants=initrd-root-fs.target, and
initrd-root-fs.target has Wants=systemd-repart.service (through symlink),
hence starting initrd-switch-root.target tries to start
systemd-repart.service,
- systemd-repart.service has Conflicts=initrd-switch-root.target, hence
starting initrd-switch-root.target tries to stop
systemd-repart.service.
As similar, interestingly(?) starting initrd-switch-root.target tries to
stop initrd-switch-root.target.
So, now there are at least two pairs of conflicting jobs:
- systemd-repart.service: start vs stop,
- initrd-switch-root.target: start vs stop.
As these jobs are induced by starting initrd-switch-root.target, of course
the most important one is the start job for initrd-switch-root.target.
Previously, as you can see in the logs at the beginning, even if
the start job for initrd-switch-root.target is important, we may first
try to resolve the conflict in systemd-repart.service, and may drop the
stop job for systemd-repart.service even if it is relevant to the start
job of initrd-switch-root.target.
This makes first we solve the pair of conflicting jobs for anchor task.
So the stop job for initrd-switch-root.target is dropped first, and the
induced start job for systemd-repart.service is automatically removed,
thus it is not necessary to solve the conflict in systemd-repart.service
anymore.
This is especially important for services that are enabled both in initrd
and after switching root. If a stop job for one of the service is
unexpectedly dropped during switching root, then the service is not stopped
before switching root, and will never start after that.
Fixes#38765.
Function execute_directories logged in a way that was meaningless
without additional context:
systemd[1]: No executables found.
In execute_strv this was partially rectified by extracting the directory
name from one of the directories and using this as the identifier. But
the directory name is not always meaningful, and can also be set from
an environment variable. Let's simplify things by providing a fixed name
that can be used consistently in all log messages. In particular this will
make error messages easier to understand if users report just the error
without additional context.
manager_add_job() -> transaction_add_job_and_dependencies() may update
dependencies when a unit is not loaded yet. Hence, we need to restart
dependency loop in that case.
Follow-up for b7777d0884 (#37465).
Fixes#38676.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able
to have it in /nix/store too like the other util-linux tools).
Since c5de7b14ae
file searching implies a new mount api syscall by default,
to trigger automounts.
But, this is not necessary in most cases, e.g. when chasing
syspath in sd-device (actually this causes regression in umockdev,
see https://github.com/martinpitt/umockdev/issues/271).
Another example is reading unit files, especially .network files,
as automount may trigger mounting network filesystems...
Also, when this is used in NSS plugins, programs that load the
plugins may fail because of spuriously configured seccomp. See #38565.
Let's not trigger automount by default, and do only when explicitly
requested.
This introduces CHASE_TRIGGER_AUTOFS, and use it in
- service manager,
- bootctl and finding ESP/xbootldr,
- sysupdate,
- mountfsd,
- systemd-mount.
There may be several more places we should trigger automount, but let's
do that later.
Follow-up for c5de7b14ae.
Fixes#38565.
Replaces #38569.
Co-authored-by: Luca Boccassi <luca.boccassi@gmail.com>
This reverts commit 490aa05ca1.
As commented https://github.com/systemd/systemd/pull/38569#discussion_r2284978273,
the commit makes autofs check bypassed. Before the commit, when
CHASE_NO_AUTOFS is set, we did not shortcut chasing paths, and refused
any autofs mount points in the path. However, with the commit, the flag
was swapped but even when CHASE_AUTOFS is unset, the autofs check may be
skipped.
To fix the issue, rather than swapping the flag, we should introduce
another flag, say CHASE_TRIGGER_AUTOFS. This revert the commit, and in a
later commit, the new flag will be introduced.
Since https://github.com/systemd/systemd/commit/c5de7b14ae2e08d267d8d75bc88934ac6aa7dcd6
file searching implies a new mount api syscall by default,
to trigger automounts.
This is problematic in NSS plugins, as they are dlopen'ed inside
processes by glibc, for two reasons.
First of all, potentially searching on a networked filesystem
automount could lead to nasty surprises, such as the process
responsible for setting up the network filesystem trying to
search on that same filesystem.
More importantly, the new mount api syscall was never part of
the filesystem seccomp filter that we provide by default, and
given mounting/remounting/bind mounting is one of the possible
ways to bypass sandboxing it is very likely not allowed when
custom filters are used in sandboxed processes, if they don't
need to do these operations otherwise.
The filesystem seccomp mask we provide has been updated, however
this only takes effect on the next restart of a service. When
systemd is upgraded via a package upgrade, the new nss plugin is
installed and will be immediately dlopen'ed by glibc when needed,
without waiting for the process to restart, which means the existing
seccomp filter applies, causing the filter to trigger.
Given it's not really possible for any arbitrary program to
predict which NSS modules glibc will load, given programs do not
configure that and instead nsswitch is set up by the sysadmin,
it's impossible to handle at each process level. It's also not
possible to know when it will be triggered, given the plugin
is not linked in each binary tools like need-restart cannot
even pre-emptively restart services that may be affected.
This means in practice, upgrading from systemd << v258 to >= v258
requires a reboot to avoid either subtle or catastrophic system
failures.
By avoiding to trigger automounts in nss-systemd we can avoid
both issues.
userdb drop-ins are searched for in:
/etc/userdb/
/run/userdb/
/run/host/userdb/
/usr/local/lib/userdb/
/usr/lib/userdb/
none of which are supported as automounts anyway.
Note that this happens only when the userdbd service is not running,
as otherwise nss-systemd will go through the varlink IPC, rather than
doing the searches in-process.
So invert CHASE_NO_AUTOFS to CHASE_AUTOFS and set it in the places where
we do want to trigger automounts, like looking for the ESP.
Follow-up for https://github.com/systemd/systemd/commit/c5de7b14ae2e08d267d8d75bc88934ac6aa7dcd6
Fixes https://github.com/systemd/systemd/issues/38565
Even watchdog for a service is stopped when freezing the unit is
requested, sd-notify message WATCHDOG=1 or friends may come after
that due to ordering of event priority. In that case,
service_reset_watchdog() is called for frozen unit and thus previously
watchdog was reenabled.
Follow-up for 25178aadb2.
Fixes#38551 (the second failure case).
Lennart Poettering
Mike Yuan
Markus Boehme
Daan De Meyer
Yu Watanabe
gvenugo3
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Arian van Putten