Let's pick up the boot ID early if unspecified, in
journal_file_append_entry(). This is symmetric to the fact that we
already pick up the monotonic timestamp in journal_file_append_entry()
if unspecified, and given that the monotonic clock is not too useful
without its boot ID it makes a lot of sense to pick them up at the same
time.
There are two relevant callers of journal_file_append_entry() right now:
journald (which leaves the boot ID unspecified) and journal-remote
(there are also some tests, but those don't matter too much). The former
calls it to store new entries in the journal file, the latter for
converting/processing/merging existing ones (where it passes along the
original boot ID). This new code hence only is relevant on the former,
and using the boot ID of the current system is the right choice for live
generated entries.
Note that this effectively changes little, since the lower-level
function journal_file_append_entry_internal() will copy boot ID stored
in the file header into all records if unspecified, and typically that's
the one of the local system. But strictly speaking this is not the right
thing to do, since we actually might end up appending to journal files
from previous boots. (The lower level function is indirectly used by
various tests, where the copying-from-header logic kinda makes sense
since they are detached from any live messages streaming in from the
host after all).
This is a follow-up for 1d8d483f59 and
makes the strict ordering by realtime clock within each journal file
optional, not mandatory. It then enables it for all journal files
written by journald, but leaves it off on others (for example those
written by journald-remote).
This relaxes the logic behind writing journal files to the status quo
ante for all cases where the journal files are not generated, but are
merged/processed/propagated. Typically when processing journal records
from many files ordering by realtime clock and monotonic clock are
contradictory, and cannot be universally guaranteed as the records are
interleaved. By enforcing strict rules we would thus end up generating
myriads of separate journal files, each with just a few records in them.
Hence, let's losen restrictions again, but continue to enforce them in
journald, i.e. when we original create the journal files locally.
Note that generally there's nothing really wring with having journal
files with non-monotonically ordered entries by realtime clock. Looking
for records will not be deterministic anymore, but that's inherent to a
realtime clock that jumps up and down. So you won't get the "only"
answer, but still *a* answer that is correct if you seek for a realtime
clock.
This also adds similar logic on the monotonic clock, which is also only
enabled when generating journal files locally. This should be harder to
trigger (as journald will generate the messages, and should run with a
stable boot id and monotonic clock), but let's better be safe than
sorry, and refuse on the lower layer what makes no sense, even if it's
unlikely the higher layer will ever generate records that aren't ordered
by their monotonic clock.
Same as the sd_pid_* counterparts, but take a pid file descriptor instead of
a pid, so that the callers can be sure that the returned values are really
about the process they asked for, and not about a recycled PID.
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.
Lennart Poettering
Jan Janssen
Zbigniew Jędrzejewski-Szmek
David Tardon
Yu Watanabe
Luca Boccassi
Franck Bui
Daan De Meyer
msizanoen1
Nick Rosbrook