For some (corner) cases, it might be desirable to disable the generation of
some persistent storage symlinks that 60-persistent-storage.rules creates.
For example on big setups with a high number of partitions which uses the same
label name, this can result in a noticeable slow-down in the (re)start of the
udevd as there are many contenders for the symlink /dev/disk/by-partlabel.
However it's currently pretty hard to overwrite just some specific part of the
rule file. Indeed one need to copy and modify the whole rule file in /etc but
will lost any upcoming updates/fixes that the distro might release in the
future.
With this simple patch, one can now disable the generation of the
"by-partlabel" symlinks (for example) with the following single rule:
$ cat /etc/udev/rules.d/99-no-by-partlabel.rules
ENV{ID_PART_ENTRY_NAME}=="?*", SYMLINK-="disk/by-partlabel/$env{ID_PART_ENTRY_NAME}"
Closes#24607.
Ensure all realtime timestamps in a journal file are strictly
ordered on write as a defense-in-depth measure. All known callers of
journal_file_append_entry and journal_file_copy_entry, which call this
function, should be able to handle the error by rotating the journal.
This is especially helpful for systems with RTC local time enabled,
where all log entries from initramfs might be recorded as several hours
later than it actually is, which won't get caught by journald during log
flushing. In those cases, the resulting inconsistency can cause libsystemd
to loop infinitely through journal files as observed in
`abrt-dump-journal-oops`.
Otherwise, when a new syspath is assigned to the sd-device object,
sd_device_get_sysname() or _sysnum() will provide an outdated device
name or number.
Let's pass USEC_INFINITY from sd_event_source_set_time_relative() to
sd_event_source_set_time() instead of raising EOVERFLOW.
We should raise EOVERFLOW only if your addition fails, but not if the
input already is USEC_INFINITY, since it's an entirely valid operation
to have an infinite time-out, and we should support that.
Allow sending notifications via AF_VSOCK, so that VMs can communicate
to the hypervisor/VMM that they are finished booting.
Note that if the hypervisor does not support SOCK_DGRAM over AF_VSOCK
(ie: qemu at the time of writing), SOCK_SEQPACKET will be used instead.
We never use the return value, and it's confusing and kinda pointless
what we return there.
Hence drop it.
Originally noticed by: tristone13th <tristone13th@outlook.com>
Alternative to: #25810
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
If a current alternative name is to be used to rename a network
interface, the alternative name must be removed first. If interface
renaming fails, restore the alternative name that was deleted if
necessary.
Commit 434a348380 ("netlink: do not fail when new interface name is
already used as an alternative name") added logic to set the old
interface name as an alternative name, but only when the new name is
currently an alternative name. This is not the desired outcome in most
cases, and the important part of this commit was to delete the new name
from the list of alternative names if necessary.
EINVAL suggests that the caller passes an invalid argument. EIO is
for "input/output error", i.e. the error you'd get if the disk or
file system is borked, and this error code could be returned by the
underlying read/write functions.
Let's make the functions return an unambiguous error code.
If an attribute is read but the value is not used (i.e. ret_value is NULL),
then sd_device_get_sysattr_value() mistakenly frees the read data even though
it is cached internally.
Fixes a bug introduced by acfc2a1d15.
Fixes#25702.
Sometimes a freeze operation can hang due to the presence of kernel
threads inside the unit cgroup (e.g. QEMU-KVM). This ensures that the
ThawUnit operation invoked by systemd-sleep at wakeup always thaws the
unit.
Previously, e.g., networkd enumerated network interfaces with ifindex
in a decreasing order, as sd-netlink inverses the order of the received
multipart messages.
Let's keep the order of the multipart messages. Hopefully this changes
no behavior, as our code do not depend on the order of the received
multipart messages.
Before:
===
Nov 26 09:35:10 systemd[1]: Starting Network Configuration...
Nov 26 09:35:11 systemd-networkd[36185]: wlp59s0: Saved new link: ifindex=3, iftype=ETHER(1), kind=n/a
Nov 26 09:35:12 systemd-networkd[36185]: enp0s31f6: Saved new link: ifindex=2, iftype=ETHER(1), kind=n/a
Nov 26 09:35:12 systemd-networkd[36185]: lo: Saved new link: ifindex=1, iftype=LOOPBACK(772), kind=n/a
After:
===
Nov 26 09:45:18 systemd[1]: Starting Network Configuration...
Nov 26 09:45:19 systemd-networkd[38372]: lo: Saved new link: ifindex=1, iftype=LOOPBACK(772), kind=n/a
Nov 26 09:45:19 systemd-networkd[38372]: enp0s31f6: Saved new link: ifindex=2, iftype=ETHER(1), kind=n/a
Nov 26 09:45:19 systemd-networkd[38372]: wlp59s0: Saved new link: ifindex=3, iftype=ETHER(1), kind=n/a
Previously, if a single packet contains multiple non-multipart messages,
then the messages were linked and saved as a single entry, especially
even if the messages has different serial numbers. Though, not sure if
the kernel sends such packet. But at least for safety, let's link only
multipart messages.
When we receive a multi-part message and fail to parse it, then
the prviously received message is freed with the _cleanup_ attribute,
but still referenced by sd_netlink.rqueue_partial. That causes
use-after-free when we receive another multi-part message.