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:
configure.ac
doc/manual.html
runtime/datetime.h
runtime/parser.c
runtime/rsyslog.h
tools/syslogd.c
v4-stable had a bug with RFC5424-formatted structured data, which showed
was detected by the enhanced automatted testbench of v4-beta.
some things inside the message can be used over a large number of
messages and need to to be allocated and re-written every time. I now
begin to implement this as a "prop_t" object, first use for the inputName.
Some input modules are already converted, some others to go. Will do
a little performance check on the new method before I go further.
Also, this commit has some cleanup and a few bug fixes that prevented
compiliation in debug mode (I overlooked this as I did not compile
for debug, what I normally do, and the automatted test also does not
do that)
Well, actually this and a lot of related things. I improved the
testbench so that the new capabilities are automatically tested and
also did some general cleanup. The current multiple tcp listener
solution will probably receive some further cleanup, too, but looks
quite OK so far. I also reviewed the way tcpsrv et all work, in
preparation of using this code for imdiag. I need to document the
findings, especially as the code is rather complicated "thanks" to
the combination of plain tcp and gssapi transport modes.
This enhances performance and, as some have pointed out, is
probably also more consistent with what users expect how
the various output-timestamp related function should work. This
commit needs some more testing.
there are still some files left which could go into the
runtime, but I think we will delete most of them once we
are done with the full modularization.
