| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
the imdiag implementation of "queue empty" was a bit racy, which
sometimes lead to too-early termination of rsyslogd and thus some
small memory leaks (which in turn showed up as problems during
make check). The current architecture is not able to 100% guard against
this, but the probleme probability has been reduced (and it showed to
improve in practice).
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
plugins/imfile/imfile.c
plugins/imklog/imklog.c
plugins/imptcp/imptcp.c
plugins/imtcp/imtcp.c
plugins/imuxsock/imuxsock.c
plugins/mmsnmptrapd/mmsnmptrapd.c
tools/omfile.c
|
| | |
| |
| |
| |
| |
| |
| | |
If the kernel time-stamps messages, time is now take from that
timestamp instead of the system time when the message was read. This
provides much better accuracy. Thanks to Lennart Poettering for
suggesting this feature and his help during implementation.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This permits to read the time a message was submitted to the system
log socket. Most importantly, this is provided in microsecond resolution.
So we are able to obtain high precision timestampis even for messages
that were - as is usual - not formatted with them. This also simplifies
things in regard to local time calculation in chroot environments.
Many thanks to Lennart Poettering for suggesting this feature,
providing some guidance on implementing it and coordinating getting the
necessary support into the Linux kernel.
|
| | |\
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
|
| | | | |
|
| | | | |
|
| | |\ \ |
|
| | | |\ \ |
|
| | | |\ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
tcpsrv.c
tests/Makefile.am
tests/tcpflood.c
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
this has not yet been added to imtcp, but could be done on request
|
| | | | | | | |
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
at the socket layer.
reference: http://kb.monitorware.com/post20791.html
|
| | |\ \ \ \ \ \ |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Conflicts:
ChangeLog
plugins/imrelp/imrelp.c
|
| | |\ \ \ \ \ \ \ \
| | | |_|_|_|_|_|/
| | |/| | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
doc/rsyslog_conf_modules.html
plugins/imrelp/imrelp.c
|
| | | |\ \ \ \ \ \ \
| | | | |_|_|_|_|/
| | | |/| | | | | |
|
| | | | | |_|_|_|/
| | | |/| | | | |
|
| | | | | | | | | |
|
| | | | |_|_|/ /
| | |/| | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | |_|/ /
| | |/| | | |
|
| | |\| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
tools/omfwd.c
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
otherwise we may waste a lot of effort...
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
now also properly works with privilege drop
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This was an experimental module which did not work out well, so
there is no point in enhancing it.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
as far as we know that new interface right now ;)
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | |/ / / /
| |/| | | |
| | | | | |
| | | | | | |
Conflicts:
tools/syslogd.c
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
reason was that a global config variable was invalidly accessed where a
listener variable should have been used.
Also performance-improved the case when rate limiting is turned off (this
is a very unintrusive change, thus done directly to the stable version).
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | | |
Conflicts:
tools/omfile.c
|
| | |\ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
if systemd writes a kernel log entry with a non-kernel priority,
the priority recorded in the kernel log will be wrong. However,
it will be immediately followed by another priority (with the
kernel timestamp in between, if enabled). So imklog now tries
to see if there is a second PRI and, if so, uses it. Note that
we already support non-kernel PRIs in the kernel log, as this
was done in BSD for quite some while. HOWEVER the config
statement "$klogpermitnonkernelfacility on" must be used to
permit this (otherwise non kernel messages are dropped).
Sample of a such a message on a kernel without timestamping
enabled:
$ echo '<14>text' > /dev/kmsg
$ dmesg -r
<4><14>text
NOTE: support for timestamp is NOT YET ENABLED!
|
| | | | | | | | |
|
