sd-device replaces '!' in sysname with '/', hence sysname may be
different from ifname.
Let's use INTERFACE property when we need network interface name.
This fixes the following unexpected renaming of network interfaces
created with '!' in their name, e.g. 'hoge!foo' -> 'hoge_foo':
```
$ run0 ip link add 'hoge!foo' type dummy
$ ip link show 'hoge!foo'
Device "hoge!foo" does not exist.
$ ip link show 'hoge_foo'
410: hoge_foo: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ee:54:4a:dd:c4:c7 brd ff:ff:ff:ff:ff:ff
```
Closes#26156.
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
E.g. sd_device object of network interface 'hoge!foo' has sysname 'hoge/foo'.
So, previously udevd assigned 'hoge/foo' rather than 'hoge!foo' to ID_NET_NAME,
hence even when renaming is not requested, such interface was renamed to 'hoge_foo'
(note '/' cannot be used in network interface name, hence escaped to underbar).
- 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 .
Yu Watanabe
Lennart Poettering
Michael Catanzaro
nkraetzschmar
Michal Koutný
David Tardon
Ivan Kruglov