Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
A lot of tests can be defined by just their filename. Moving into their
own list keeps things simpler, especially with the next commit. It also
makes it easier to keep the lists sorted.
We nowadays check for ordering anyway at time of writing entries, hence
we don't have to do that at moment of opening, too.
Benefit of dropping this check: we can safely archive files from the
future instead of marking them as broken.
We allow reading them, and we allow creating them, but we so far did not
allow opening existing ones for write – if the machine ID is not
initialized.
Let's fix that.
(This is just to fix an asymmetry. I have no immediate use for this. But
test code should in theory be able to use this, if it runs in an
incompletely initialized environment.)
Previously, if we ran in an environment where /etc/machine-id was
not defined, we'd never bother to write it ever again. So it would stay
at all zeroes till the end of times.
Let's make this more robust: whenever we try to append an entry, let's
try to refresh it from the status quo if not initialized yet. Moreover,
when copying records from a different journal file, let's propagate the
machine ID from there.
This should make things more robust and systematic, and match how we
propagate the boot ID and the seqnum ID to some level.
This doesn't actually change much, but makes the code less surprising.
Status quo ante:
1. Open a journal file
2. If newly created set header machine ID to zero
3. If existing and open for write check if machine ID in header matches
local one, if not, refuse.
4. if open for writing, now refresh the machine ID from the local system
Of course, step 4 is pretty much pointless for existing files, as the
check in 3 made sure it is already in order or we'd refuse operating on
it anyway. With this patch this is simplified to:
1. Open a journal file
2. If newly created initialized machine ID to local machine ID
3. If existing, compare machine ID in header with local one, if not
matching refuse.
Outcome is the same.
The header of the journal file contains a boot ID field that is
currently updated whenever we open the journal file. This is not ideal:
pretty often we want to archive a journal file, and need to open it for
that. Archiving a foreign journal file should not mark it as ours, it
should just change the status flag in the file header.
The boot ID in the header is aleady rewritten whenever we write a
journal entry to the file anyway, hence all this patch effectively does
is slightly "delay" when the boot ID in the header is updated: instead
of immediately on open it is updated on the first entry that is written.
Net effect: archived journal files don't all look like they were written
to on a boot newer then they actually were
And more importantly: the "tail_entry_monotonic" field suddenly becomes
useful, since we know which boot it belongs to. Generally, monotonic
timestamps without boot ID information are useless, and this fixes it.
A new (compatible) header flag marks file where the boot_id can be
understood this way. This can be used by code that wants to make use of
the "tail_entry_monotonic" field to ensure it actually can do so safely.
This also renames the structure definition in journal-def accordingly,
to indicate we now follow the stricter semantics for it.
Currently we allocate fixed-size memory for event sources: the largest
any of the event source type needs. Discrepancy in the sizes needed for
the various event sources is quite major however: it's 144 bytes on
x86_64, i.e. more than two cache lines.
hence, let's be a tiny bit more careful, and allocate exactly as much as
we need, but not more.
This does what 404803e6ca did for the
monotonic timestamp getter, but for the realtime timestamp.
It also also makes the return value optional, exactly as for the
monotonic timestamp logic.
Let's ensure that entry seqnums remain stable and monotonic across the
entire runtime of the system, even if local storage is turned off. Let's
do this by maintainer a counter file in /run/ which we mmap() and
wherein we maintain the counter from early-boot on till late shutdown.
This takes inspiration of the kernel-seqnum file we already maintain
like that that tracks which kmsg messages we already processed. In fact,
we reuse the same code for maintaining it.
This should allow the behaviour entry seqnums to be more predictable, in
particular when journal local storage is turned off. Previously, we'd
maintain the seqnum simply by always bumping it to the maximum of the
last written entry seqnum plus one, and the biggest seqnum so far
written to the journal file on disk. If we'd never write a file on disk,
or if no journal file was existing during the initrd→seqnum transition
we'd completely lose the current seqnum position during daemon restarts
(such as the one happening during the switch-root operation).
This also will cause a journal file rotation whenever we try to write to
a journal file with multiple sequence number IDs, so that we know that
from early boot trhough the entire runtime we'll have stable sequence
numbers that do not jump, and thus can be used to determine "lost"
messages.
This result is identical after cpp is done, so we don't save anything
by not having the usual macros. And with the usual macros it's easier to
grep and code-crossreferencing works better.
I tried to use DECLARE_FLEX_ARRAY like the kernel does, but it does not work
for anonymous structs (they cannot be declared inline), so an open-coded
version is used.
We keep adding fields to the header, and it's fine reading files with
different header sizes, as we check via the size if the fields we need
are included. However, let's be stricter when writing journal files than
when reading, and insist that the header structure in the file actually
matches our expectations. Refuse otherwise, so that a new file is
created after rotation that then matches our expectations.
This makes sure that mismatch in header size is treated exactly as
unknown "compatible" flags, which is our other mechanism to allow
extending the journal file format in a non-breaking way.
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.
Jan Janssen
Lennart Poettering
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
David Tardon
Franck Bui