GCC manual states that "For an enum, struct or union type, you may
specify attributes either between the enum, struct or union tag and
the name of the type, or just past the closing curly brace of the
definition. The former syntax is preferred." This means that the
attribute should not be located before 'struct'. Putting it between
'struct' and the name seems cluttered. Putting it at the end seems
most readable.
This avoids clang warnings.
../src/journal/journal-send.c: In function 'sd_journal_sendv':
../src/journal/journal-send.c:250:73: warning: pointer of type 'void *' used in arithmetic [-Wpointer-arith]
This introduces a new data threshold setting for sd_journal objects
which controls the maximum size of objects to decompress. This is
relieves the library from having to decompress full data objects even
if a client program is only interested in the initial part of them.
This speeds up "systemd-coredumpctl" drastically when invoked without
parameters.
Sometimes it is better to see messages in full, and the existing
set of options didn't allow this easily. E.g. now
journalctl -f --full
will behave like
tail -f /var/log/messages
of yore.
Long option only for now, since small letters are becoming
scarce, and this doesn't feel like a capital-letter-option.
'-u' would be nice, and the above command would be spelled
journalctl -fu
The path doesn't change in the standard configuration.
Also, give full path to the journalctl binary in the hook,
since it might be installed outside of $PATH.
Also, add uninstall hook to remove the binary catalog.
Some filesystem magics are too big to fit in 31 bits,
and are wrapped to negative. f_type is an int on 32 bits, so
it is signed, and we get a warning on comparison.
The message catalog can be used to attach short help texts to log lines,
keyed by their MESSAGE_ID= fields. This is useful to help the
administrator understand the context and cause of a message, find
possible solutions and find further related documentation.
Since this is keyed off MESSAGE_ID= this will only work for native
journal messages.
The message catalog supports i18n, and is useful to augment english
language system messages with explanations in the local language.
This commit only includes short explanatory messages for a few example
message IDs, we'll add more complete documentation for the relevant
systemd messages later on.
The point is to allow the use of journald functions by other binaries.
Before, journald code was split into multiple files (journald-*.[ch]),
but all those files all required functions from journald.c. And
journald.c has its own main(). Now, it is possible to link against
those functions, e.g. from test binaries.
This constitutes a fix for https://bugzilla.redhat.com/show_bug.cgi?id=872638.
The patch does the following:
1. rename journald.h to journald-server.h and move corresponding code
to journald-server.c.
2. add journald-server.c and other journald-*.c parts to
libsystemd-journal-internal.
3. remove journald-syslog.c from test_journal_syslog_SOURCES, since
it is now contained in libsystemd-journal-internal.
There are no code changes, apart from the removal of a few static's,
to allow function calls between files.
Network file systems generally do not offer inotify() that would work
across the network. We hence cannot rely on inotify() exclusiely in
those case. Provide an API to determine these cases, and suggest doing
manual regular rechecks.
Note that this is not complete yet, as we need to rescan journal dirs on
network file systems explicitly to find new/removed files
When traversing entry array chains for a bisection or for retrieving an
item by index we previously always started at the beginning of the
chain. Since we tend to look at the same chains repeatedly, let's cache
where we have been the last time, and maybe we can skip ahead with this
the next time.
This turns most bisections and index lookups from O(log(n)*log(n)) into
O(log(n)). More importantly however, we seek around on disk much less,
which is good to reduce buffer cache and seek times on rotational disks.
'systemd-coredumpctl' will list available coredumps:
PID UID GID sig exe
32452 500 500 11 /home/zbyszek/systemd/build/journalctl
32666 500 500 11 /usr/lib64/valgrind/memcheck-amd64-linux
...
'systemd-coredumpctl dump PID' will write the coredump
to specified file or stdout.
Zbigniew Jędrzejewski-Szmek