There are way too many users configuring the DNS= setting by mistake,
because what it seems to do is different from what it actually does. We
do not have consensus to change its behavior, so let's at least add a
warning comment.
Fixes#33973
- Fixes a race in systemd-run caused by
b7ba8d55b8, which causes issue #36679.
- Skip verifying masked units in TEST-23.
- Avoid false-positive ASan warning by switching sanitizer run from
Fedora rawhide to Fedora 41, caused by recent update from
llvm-19.1.7-11.fc43 to llvm-20.1.0-1.fc43. Hopefully issue #36678 should
be fixed.
Closes#36678.
Closes#36679.
LXC helper processes hide themselve in .lxc cgroup, we don't have to
deal with the inside tests (and the error in conversion to unit is handled).
Skip those but keep iterating over remaining processes to detect what
can be created around us.
cg_pidref_get_path() cannot work (current implementaion) without
cgroupfs (when it checks unified or not setup). Similarly,
cg_pidref_get_unit() assumes all processes are part of a unit. So carry
out the test only when running on a systemd setup.
The test is supposed to check a battery of cgroup helpers on each
process found but it doesn't literally check anything besides presence
of procfs. (One can visually check printed output only. Introduction in
aff38e74bd ("nspawn: suffix the nspawn cgroups with ".nspawn"").)
Make some assumptions about visible processes and turn the test into
testing that systemd helpers can deal with whatever process they find on
the SUT.
Reported by Coverity and
Fixes CID#1587767
So I have a bunch of particle os instances around, that I frequently
factory reset. and it's confusing, since they all have the same name.
Let's do something about this, and extend the hostname setup logic a bit
to deal better with "cattle" rather than "pet" deployments.
Specifically: if a hostname in /etc/hostname contains a bunch of
question marks we'll replace it with hex chars hashed from the machine
id.
This allows us to do something like this:
hostnamectl set-hostname --static 'funky-????-????-???'
and we'll end up with a hostname like `funky-baf4-b653-e230`
Otherwise, if systemd-run is disconnected from bus before JobRemoved
signal, then c->start_job will never freed, thus run_context_check_done()
will never call sd_event_exit() even after the service is finished.
This drops monitoring JobRemoved signal, and make systemd-run check if
the start job is started when PropertiesChanged signal is received.
Follow-up for b7ba8d55b8.
Fixes#36679.
It seems the recent update of LLVM package in Fedora rawhide breaks
sanitizers, and udevd freezes after false-positive (I guess) issue is
detected:
systemd-udevd[2646]: =================================================================
systemd-udevd[2646]: ==2646==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ffc3a642660 at pc 0x555627ac022b bp 0x7ffc3a6422b0 sp 0x7ffc3a6422a8
systemd-udevd[2646]: READ of size 8 at 0x7ffc3a642660 thread T0 ((udev-worker))
llvm-19.1.7-11.fc43 worked fine, but llvm-20.1.0-1.fc43 does not.
To avoid the issue, let's enable sanitizer on Fedora 41, and disable it
on Fedora rawhide.
Closes#36678.
This fixes the following failure:
TEST-23-UNIT-FILE.sh[2408]: + systemd-analyze --recursive-errors=no --man=no verify /usr/lib/systemd/system/sysinit.target.wants/systemd-hwdb-update.service
systemd-analyze[2737]: sys-kernel-config.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: proc-sys-fs-binfmt_misc.automount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: dev-hugepages.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: sys-kernel-tracing.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: sys-kernel-debug.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: sys-fs-fuse-connections.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: dev-mqueue.mount: symlinks are not allowed for units of this type, rejecting.
systemd-analyze[2737]: Unit systemd-hwdb-update.service is masked.
TEST-23-UNIT-FILE.sh[166]: + :
TEST-23-UNIT-FILE.sh[166]: + kill -0 2408
TEST-23-UNIT-FILE.sh[166]: + wait 2408
TEST-23-UNIT-FILE.sh[166]: + echo 'Subtest /usr/lib/systemd/tests/testdata/units/TEST-23-UNIT-FILE.verify-unit-files.sh failed'
TEST-23-UNIT-FILE.sh[166]: Subtest /usr/lib/systemd/tests/testdata/units/TEST-23-UNIT-FILE.verify-unit-files.sh failed
When mounting a disk image we return a bunch of mount fds referencing
the various partitions in the disk, along with some metadata about them.
One key metadata field is the "designator" which is supposed to tell
clients what is what, and where to mount it.
Let's make this more explicit: let's also include the literal relative
path where each mount shall be placed, to simplify implementations of
clients that do not care about the concept of designators.
In one of the next commits we'd like to introduce a concept of
optionally hashing the hostname from the machine ID. For that we we need
to optionally back gethostname_full() by code involving sd-id128, hence
let's move it from src/basic/ to src/shared/, since only there we are
allowed to use our public APIs.
A D-Bus/Varlink method can issue PolicyKit auth. requests for multiple
actions; in this case the method is expected to fail on the first one
that is not allowed. This is enforced by asserts in
async_polkit_read_reply(), but that's a wrong place for the check for
two reasons:
1. it doesn't allow to get a meaningful stack trace;
2. sending the query to polkit is already a pointless exercise.
Let's do the check in *_verify_polkit_async_full() and don't send
anything to PolicyKit in that case.
Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=2349594 .
The capsule instances are related to user instances, so treat them
equally to user@.service when handling cgroup paths. This also saves us
from polluting public libsystemd API with variant for capsules too.
Fix: https://github.com/systemd/systemd/issues/36098
The capsule instances are related to user instances, so treat them
equally to user@.service when handling cgroup paths. This also saves us
from polluting public libsystemd API with variant for capsules too.
Fix: #36098
We have RestartMaxDelaySec= + RestartSteps= to exponentially increase
auto restart durations, but it currently cannot be reset by the service
itself, which makes it sometimes awkward to use. A typical pattern
in real life is that a service was once down (e.g. due to temporary
network interruption) and multiple restarts were attempted. Then,
future restarts would always wait for increated amount of time based on
RestartMaxDelaySec=, even after the original problem got resolved.
Such "persistence" could result in longer unavailablity than there
should be for failures that come later.
(C.f. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdResettingUnitBackoff)
Let's introduce a new sd_notify() notification for resetting the restart
counter. There were discussions about making this timer-based, but I think
it's more flexible to leave the decision-making to the service. This enables
them to do a combination of N successful requests + uptime check for instance.
Rereading partition table may take longer on slow disk. The main process
should not be blocked by the operation. Let's fork a child process and
do that on the child.
Prompted by #36624 and #36269.
If a network mount returns EBUSY on umount, the logic introduced in
6dc68a00cf causes shutdown to hang indefinitely on
`fstatat()` (i.e., within `is_dir(m->path, true)`). Hence, skip this logic for
network mounts (following the same motivation we use to skip read-only mounts in
this kind of file systems).
Fixes 6dc68a00cf
Michael Catanzaro
Yu Watanabe
Lennart Poettering
nkraetzschmar
Michal Koutný
David Tardon
Ivan Kruglov
Mike Yuan
Antonio Alvarez Feijoo