[systemd-devel] systemd-logger and external syslog daemon

[Rainer Gerhards]

> -----Original Message-----
> From: Michael Biebl [mailto:mbiebl at gmail.com]
> Sent: Friday, March 11, 2011 8:20 AM
> To: Rainer Gerhards
> Cc: Andrey Borzenkov; Mike Kazantsev; systemd-
> devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] systemd-logger and external syslog daemon
> 
> 2011/3/11 Rainer Gerhards <rgerhards at hq.adiscon.com>:
> >> -----Original Message-----
> >> From: Michael Biebl [mailto:mbiebl at gmail.com]
> >> Sent: Friday, March 11, 2011 8:04 AM
> 
> >> Mar 11 07:56:27 pluto kernel: [ 5921.140864] michael[25078]: baz
> >>
> >> As you can see, when rsyslog starts up and flushes the kmsg queue,
> >> the log messages all have the same timestamp (Mar 11 07:56:27) and
> >> they come after the rsyslog startup message, although they were
> >> logged before the  rsyslog start.
> >> Lennart argues, that this should be handles within the syslogd (in
> >> this case rsyslog 5.7.8), which should use the kernel time stamp to
> >> compute the correct time when the log message occured.
> >>
> >> Rainer, can you share any insight on this matter?
> >
> > Lennart recommended that to me and I had some code in place to do it.
> > However, at that time this did not work because the kernel did not
> > record that timestamp. This was added a while later, but I did not yet
> > revisit that issue. I was a bit hesitant to dig into this issue as I
> > found no simple enough method to setup a system with systemd (I know
> > it's important, but there are many other important things as well...).
> > I'll see that I can at least see what kernel patch needs to be present.
> 
> afaik it is not so much a kernel version issue, but a kernel config that
needs to
> be turned on:
> http://cateee.net/lkddb/web-lkddb/PRINTK_TIME.html says it's available ins
> 2.6.12
> 
> Debian kernels have CONFIG_PRINTK_TIME=y Ubuntu 10.10 and F14 as it
> seems, too.

So isn't that already a solution?

Lennart suggested to use the SO_TIMESTAMP control data options, which makes
perfectly sense. Unfortunately, this was not implemented for AF_UNIX. I just
checked, and the relevant patch seems to have been merged in Kernel 2.6.37.

Rainer