| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Follow-up for #27488.
|
|
|
|
|
| |
Especially when using in-memory logging, these are too noisy so
let's drop them back to debug level.
|
|
|
|
|
|
|
| |
On RISCV32, time_t is 64bit and size_t is 32bit, hence the timestamp
data in message header may not be aligned.
Fixes #27241.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All daemons use a similar scheme to read their main config files and theirs
drop-ins. The main config files are always stored in /etc/systemd directory and
it's easy enough to construct the name of the drop-in directories based on the
name of the main config file.
Hence the new helper does that internally, which allows to reduce and simplify
the args passed previously to config_parse_many_nulstr().
Besides the overall code simplification it results:
16 files changed, 87 insertions(+), 159 deletions(-)
it allows to identify clearly the locations in the code where configuration
files are parsed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's log exactly at one place about failed writing of log lines to
journal file: in shall_try_append_again().
Then, if we decide to suppress a retry-after-vacuum because we already
vacuumed anyway then say this explicitly as "supressed rotation",
because that's what we do here.
This removes triplicate logging about the same error, and logs exactly
once, plus optional one "suppressed rotation" message. (plus more debug
output). The triplicate logging was bad in particular because it had no
understanding of the actual error codes and just showed generic UNIX
error strings ("Not a XENIX named type file"). By relying on
shall_try_append_again() to do all logging we now get very clean error
strings for all conditions.
Fixes: #26496
|
|
|
|
|
|
|
|
| |
it with %m
We always want to pass the error code along with the log call, so that
it can add it to structured logging, even if the format string does not
contain %m.
|
|
|
|
|
| |
in this case we really cannot proceed and fail. Let's log about this
loudly, since we simply fail the operation to write anything.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
None of these conditions are real issues, but they can simply happen
because we just swtched from /run to /var as backend for logging and
there are old files from different boots with different systemd versions
and so on.
Let's not make more noise than necessary: still log, but not consider it
a warning, but just some normal thing.
We are handling these issues safely after all: by rotating and starting
anew, i.e. there's no reason to be concerned.
|
| |
|
|
|
|
| |
passed in, not just some
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
Just some search/replace, no real code changes.
The majority of functions already followed this rule, but some did not.
Fix that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up for 1d8d483f59ffa62974772fb58a8ef4abe88550ec 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.
|
|
|
|
| |
No functional change.
|
| |
|
|
|
|
|
|
|
| |
The name was misleading because the function actually archives offline
journals, ie it doesn't try to remove them to make some room.
No functional change.
|
|
|
|
|
|
|
|
|
|
| |
Before this patch the only way to prevent journald from reading the audit
messages was to mask systemd-journald-audit.socket. However this had main
drawback that downstream couldn't ship the socket disabled by default (beside
the fact that masking units is not supposed to be the usual way to disable
them).
Fixes #15777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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.
|
|
|
|
|
|
| |
Follow-up for: 379864f89079a92ff09917e25b3aea0fadd228ac
Two PRs clashed with each other and were merged before we noticed
|
|
|
|
|
|
|
|
|
|
|
|
| |
The journal has a mechanism to log to the runtime journal if it fails to
log to the system journal. This mechanism is not triggered when the file
system becomes read-only. We enable it here.
When appending an entry fails if shall_try_append_again returns true,
the journal is rotated. If the FS is read-only, rotation will fail and
s->system_journal will be set to NULL. After that, when find_journal
will try to open the journal since s->system_journal will be NULL, it
will open the runtime journal.
|
|
|
|
|
| |
Instead of maintaining two different constants, move the constant
to journal-internal.h and share it between files.
|
|
|
|
|
|
| |
The compiler should recognize that these are constant expressions, but
let's better make this explicit, so that the linker can safely share the
initializations all over the place.
|
|
|
|
|
| |
These don't make sense anymore since we disable log ratelimiting
when logging at debug level.
|
|
|
|
|
|
| |
systemd-journald is prone to spamming logs if the system gets into
a messy state. Let's improve the situation by ratelimiting logs on
the hot code paths to 3 times per minute.
|
|
|
|
| |
Allows configuring the ratelimit per logging statement.
|
|
|
|
|
|
|
|
|
| |
I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
errno + %m
strerror() is not thread safe and calling it just isn't worth the effort
required to justify why it would be safe in those cases. It's easier to just
use %m which is thread-safe out of the box. I don't think that any of the
changes in the patch cause any functional difference. This is just about
getting rid of calls to strerror() in general.
When we print an error message and fail to format the string, using something
like "(null)" is good enough. This is very very unlikely to happen anyway.
|
| |
|
|
|
|
| |
gcc will complain about all these with -Wformat-signedness.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the field "_SYSTEM_CONTEXT" knew he values "initrd" + "main". Let's change
this to "_RUNTIME_SCOPE" and "initrd" + "system".
Why? The sysext logic has a very similar concept of "scopes", declaring
whether a sysext image is intended for the initrd or the main system.
Let's thus use the same naming for both.
sysext's extension-release files hence know SYSEXT_SCOPE=initrd|system,
and the journal messages know _RUNTIME_SCOPE=initrd|system, which makes
this reasonably systematic.
Follow-up for: cae8edd93ca2ef90c41cb9b6322b6908d12947b5
(This is not an API break, since no version with this commit has ever
been released.)
|
| |
|
|
|
|
|
| |
The _INITRD field is a boolean field (0 or 1) that specifies whether
a message was processed by systemd-journald in the initrd or not.
|
| |
|
|
|
|
| |
This will be used to save the list of drop-in files for each partition
|
|
|
|
| |
to void type
|
| |
|
| |
|
|\
| |
| | |
journald: don't let SIGTERM starve indefinitely
|
| |
| |
| |
| | |
Fixes: #22642
|
|/
|
|
|
|
|
| |
Just some modernization/refactoring.
No change in behaviour, just let's do how we do things these days: use
flags param instead of list of bools.
|
|
|
|
|
| |
JournalFile and JournaldFile are hard to distinguish from each other.
Let's use ManagedJournalFile instead to make the distinction more clear.
|
| |
|