nscd is known to be racy [1] and it was already deprecated and later dropped in
Fedora a while back [1,2]. We don't need to support obsolete stuff in systemd,
and the cache in systemd-resolved provides a better solution anyway.
We announced the plan to drop nscd in d44934f378.
[1] https://fedoraproject.org/wiki/Changes/DeprecateNSCD
[2] https://fedoraproject.org/wiki/Changes/RemoveNSCD
The option is kept as a stub without any effect to make the transition easier.
Currently, unit_setup_cgroup_runtime() is called in
various _coldplug() functions if the unit is not inactive.
That seems unnecessary though, and kinda defeats the purpose
of CGroupRuntime. If we need to fork off a process for the unit
or got something during deserialization, the CGroupRuntime
would be automatically set up by unit_prepare_exec() /
cgroup_runtime_deserialize_one(). Otherwise it would mean
the cgroup doesn't exist and we don't need to allocate
that in the first place.
Plus, note that socket units might also carry a cgroup with
ExecStartPre=/ExecStartPost=/... Hence the existing code
is really inconsistent.
Since the introduction of CGroupRuntime, there's no need
to call *_reset_accounting in unit_new(), hence make those
static. While at it, refrain from hardcoding default values
in cgroup_runtime_new(), but call the corresponding funcs.
This also corrects the default value of io_accounting_base.
Fixes#33482
No functional change, just deduplicate default values
in cgroup_runtime_free() and remove pointless call in
unit_free() (at the time it's called the CGRuntime has
been destroyed already).
It turns out OverlayFS doesn't handle gracefully when the same source is
specified multiple times in lowerdir= and it fails with ELOOP:
Failed to mount overlay (type overlay) on /run/systemd/mount-rootfs/opt (MS_RDONLY "lowerdir=/run/systemd/unit-extensions/1/opt:/run/systemd/unit-extensions/0/opt:/run/systemd/mount-rootfs/opt"): Too many levels of symbolic links
This happens even if we mount each image in a different internal mount
path, as OverlayFS will resolve it and look for the backing device, which
will be the same device mapper entity, and return a hard error.
This error does not appear if dm-verity is not used, so it is very
confusing for users, and unnecessary.
When mounting ExtensionImages, check if an image is dm-veritied,
and drop duplicates if the root hashes match, to avoid this user-unfriendly
hard error.
The kernel's sched_setattr interface allows for more control over a processes
scheduling attributes as the previously used sched_setscheduler interface.
Using sched_setattr is also the prerequisite for support of utilization
clamping (UCLAMP [1], see #26705) and allows to set sched_runtime. The latter,
sched_runtime, will probably become a relevant scheduling parameter of the
EEVDF scheduler [2, 3], and therefore will not only apply to processes
scheduled via SCHED_DEADLINE, but also for processes scheduled via
SCHED_OTHER/SCHED_BATCH (i.e., most processes).
1: https://docs.kernel.org/next/scheduler/sched-util-clamp.html
2: https://lwn.net/Articles/969062/
3: https://lwn.net/ml/linux-kernel/20240405110010.934104715@infradead.org/
Before 12001b1bf0, write() is required for
if Type=exec. However, with the previous commit, now write() is also used
for sending handoff timestamp. Let's allow write() if necessary.
Fixes a regression caused by 12001b1bf0.
Fixes#33299.
Before 12001b1bf0, the timestamp is sent
with write(), but the commit made the timestamp sent by send(), and
causes regressin #33299.
Note the invocation will still fail if write() is filtered by seccomp.
But, that is an old issue since Type=exec is introduced
(5686391b00).
Partially fixes a regression caused by 12001b1bf0.
Partially fixes#33299.
The purpose of the check is to prevent leaking API VFS fds
from host into a mount namespace/container. When mountns
is not used at all, the check is pointless and causes
inconvenience. E.g. file managers might need to be spawned
under those directories, and they surely won't run in mountns.
Suggested in https://github.com/systemd/systemd/pull/33454#issuecomment-2186351467Fixes#33361
As discussed in https://github.com/systemd/systemd/pull/32724#discussion_r1638963071
I don't find the opposite reasoning particularly convincing.
We have ProtectHome=tmpfs and friends, and those can be
pretty much trivially implemented through TemporaryFileSystem=
too. The new logic brings many benefits, and is completely generic,
hence I see no reason not to expose it. We can even get more tests
for the code path if we make it public.
And drop spurious assertion.
Fortunately, the previous logic worked, as /run/systemd/unit-private-tmp
is ordered earlier than /tmp or /var/tmp. But, let's ensure the tmpfs
mounted earlier to make the logic clearer.
Follow-up for 0e551b04ef.
This also
- merges basic/linux and shared/linux,
- moves BPF_JUMP_A() to basic/missing_bpf.h,
- copies from usrspace kernel headers directory generated by 'make headers',
rather than copying from kernel tree,
- copies const.h into our tree to reduce change in ethtool.h,
- copies auto_fs.h into our tree to reduce change in auto_dev-ioctl.h.
DynamicUser= enables PrivateTmp= implicitly to avoid files owned by reusable uids
leaking into the host. Change it to instead create a fully private tmpfs instance
instead, which also ensures the same result, since it has less impactful semantics
with respect to PrivateTmp=yes, which links the mount namespace to the host's /tmp
instead. If a user specifies PrivateTmp manually, let the existing behaviour
unchanged to ensure backward compatibility is not broken.
Follow-up for fc67a943d9
After the mentioned comment, we no longer need to record
the owner to restore the previous bus owner state.
Therefore, bus_name_owner is effectively unused. Kill it.
Zbigniew Jędrzejewski-Szmek
Mike Yuan
Luca Boccassi
Florian Schmaus
Yu Watanabe
Lennart Poettering