Age | Commit message (Collapse) | Author |
|
|
|
When I tryed to run journalctl with --follow and --since arguments it
behaved very strangely.
First It prints logs from what I specified in --since argument, then
printed 10 lines (as is default in --follow) and when app put something
new in to log journalctl printed everithing from the last printed line.
How to reproduce:
1. run: journalctl -m --since 14:00 --follow
Then you'll see 10 lines of logs since 14:00. After that wait until some
app add something in the journal or just run `systemd-cat echo test`
2. After that journalctl will print every single line since 14:00 and will
follow as expected.
As long as --since and --follow will eventually print all relevant
lines, I seen no reason why not to print them right away and not after
first new message in journal.
Relevant bugzillas:
https://bugs.freedesktop.org/show_bug.cgi?id=71546
https://bugs.freedesktop.org/show_bug.cgi?id=64291
|
|
/proc/[pid]:
- status
- maps
- limits
- cgroup
- cwd
- root
- environ
- fd/ & fdinfo/ joined in open_fds
|
|
systemd-journald would refuse to start if it received an unknown
socket from systemd. This is annoying, because the failure more for
systemd-journald is unpleasant: systemd will keep restarting journald,
but most likely the same error will occur every time. It is better
to continue. journald will try to open missing sockets on its own,
so things should mostly work.
One question is whether to close the sockets which cannot be parsed or
to keep them open. Either way we might lose some messages. This
failure is most likely for the audit socket (selinux issues), which
can be opened multiple times so this not a problem, so I decided to
keep them open because it makes it easier to debug the issue after the
system is fully started.
|
|
Also, make all parsing of the kernel cmdline non-fatal.
|
|
After all, this is about files, not arguments, hence EFBIG is more
appropriate than E2BIG
|
|
|
|
|
|
|
|
|
|
have anyway
|
|
Let's make the log output more readable, and the header can be
reconstructed in full from the other fields
|
|
|
|
Similar to auditd actually turn on auditing as we are starting. This way
we can operate entirely without auditd around.
|
|
audit doesn't support timestamps anyway
|
|
|
|
|
|
journal files based on a size/time limit
This is equivalent to the effect of SystemMaxUse= and RetentionSec=,
however can be invoked directly instead of implicitly.
|
|
|
|
|
|
|
|
|
|
provided headers
|
|
|
|
in /dev/shm
Previously when a log message grew beyond the maximum AF_UNIX/SOCK_DGRAM
datagram limit we'd send an fd to a deleted file in /dev/shm instead.
Because the sender could still modify the file after delivery we had to
immediately copy the data on the receiving side.
With memfds we can optimize this logic, and also remove the dependency
on /dev/shm: simply send a sealed memfd around, and if we detect the
seal memory map the fd and use it directly.
|
|
coverity otherwise assumes that the chain object might be NULL.
|
|
Commit 74055aa762 'journalctl: add new --flush command and make use of
it in systemd-journal-flush.service' broke flushing because journald
checks for the /run/systemd/journal/flushed file before opening the
permanent journal. When the creation of this file was postponed,
flushing stoppage ensued.
|
|
http://bugs.debian.org/766598
|
|
|
|
|
|
Anything that uses hashmap_next() almost certainly cares about the order
and needs to be an OrderedHashmap.
|
|
Order matters here. It replaces oldest entries first when
USER_JOURNALS_MAX is reached.
|
|
The order of entries may matter here. Oldest entries are evicted first
when the cache is full.
(Though I don't see anything to rejuvenate entries on cache hits.)
|
|
new mac_{smack,selinux,apparmor}_xyz() convention
|
|
systemd-journal-flush.service
This new command will ask the journal daemon to flush all log data
stored in /run to /var, and wait for it to complete. This is useful, so
that in case of Storage=persistent we can order systemd-tmpfiles-setup
afterwards, to ensure any possibly newly created directory in /var/log
gets proper access mode and owners.
|
|
string_is_safe()
After all, we know have this as generic validator, so let's be correct
and use it wherver applicable.
|
|
runtime journal is migrated to system journal when only
"/run/systemd/journal/flushed" exist. It's ok but according to this
the system journal directory size(max use) can be over the config. If
journal is not rotated during some time the journal directory can be
remained as over the config(or default) size. To avoid, do
server_vacuum just after the system journal migration from runtime.
|
|
names
|
|
|
|
|
|
|
|
sd_journal_enumerate_unique will lock its mmap window to prevent it
from being released by calling mmap_cache_get with keep_always=true.
This call may return windows that are wider, but compatible with the
parameters provided to it.
This can result in a mismatch where the window to be released cannot
properly be selected, because we have more than one window matching the
parameters of mmap_cache_release. Therefore, introduce a release_cookie
to be used when releasing the window.
https://bugs.freedesktop.org/show_bug.cgi?id=79380
|
|
As of 0f99f74a14 'sd-journal: verify that object start with the field
name' this condition should never happen.
|
|
systemctl would call sd_j_enumerate_unique() interleaved with
sd_j_next(). But the latter can remove a file if it detects an
error in it. In those circumstances sd_j_enumerate_unique would
restart with the first file in hashmap. With many corrupted files
sd_j_enumerate_unique might iterate over the list multiple times.
Avoid this by jumping to the next file in unique list if possible,
or setting a flag that tells sd_j_enumerate_unique that it is done
otherwise.
|
|
Also, let's try to make function names descriptive, instead of using
bools for flags.
|
|
The --utc option was introduced by commit
9fd290443f5f99fca0dcd4216b1de70f7d3b8db1.
Howerver, the implementation was incomplete.
|
|
Introduce option to display time in UTC.
|
|
They are not legal in the export format.
|
|
|
|
Found by coverity. Fixes: CID#1237512
|