| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Basically:
find . -name '*.[ch]' | while read f; do perl -i.mmm -e \
'local $/;
local $_=<>;
s/log_(debug|info|notice|warning|error|emergency)\("([^"]*)%s"([^;]*),\s*strerror\(-?([->a-zA-Z_]+)\)\);/log_\1_errno(\4, "\2%m"\3);/gms;print;' \
$f; done
Plus manual indentation fixups.
|
|
|
|
It corrrectly handles both positive and negative errno values.
|
|
As a followup to 086891e5c1 "log: add an "error" parameter to all
low-level logging calls and intrdouce log_error_errno() as log calls
that take error numbers", use sed to convert the simple cases to use
the new macros:
find . -name '*.[ch]' | xargs sed -r -i -e \
's/log_(debug|info|notice|warning|error|emergency)\("(.*)%s"(.*), strerror\(-([a-zA-Z_]+)\)\);/log_\1_errno(-\4, "\2%m"\3);/'
Multi-line log_*() invocations are not covered.
And we also should add log_unit_*_errno().
|
|
Also, while we are at it, introduce some syntactic sugar for creating
ERRNO= and MESSAGE= structured logging fields.
|
|
- Rename log_meta() → log_internal(), to follow naming scheme of most
other log functions that are usually invoked through macros, but never
directly.
- Rename log_info_object() to log_object_info(), simply because the
object should be before any other parameters, to follow OO-style
programming style.
|
|
|
|
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
|
