[lkml]   [1999]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: i386/RTC: old problem, new solution?
Hi Richard.

>>> I don't see that. Provided you update the system clock before
>>> starting syslogd, the times recorded will be correct. The kernel
>>> ring buffer doesn't store timestamps. It's syslogd that adds the
>>> timestamps.

>> So the times appearing in /var/log/messages are the times when
>> syslogd put its grubby paws on the message then, and not when it
>> was issued?

> Yep.

>> Maybe I'm being stupid, but it seems to me that having the kernel
>> tag the timestamp when the message was generated onto the message
>> would help with tracking down races as it would provide a better
>> idea of just when various problems occurred...

> I don't think you really need that. The kernel messages are
> stored in time order anyway. That's generally good enough to
> debug races.

The problem as I see it is that syslogd's timestamps MUST sometimes
imply races that aren't there, simply because it will timestamp an
entire batch of messages with near enough the same time when they were
actually spread out by several seconds, or even minutes on occasions.

Take the messsages generated during booting: If your point is correct,
then all messages generated prior to syslogd/klogd starting up are
marked with effectively the same timestamp (namely the moment when
syslogd reads them), no matter how long apart they really were, and as
a result, any races that would've shown up with the true timestamps
are of necessity hidden and can only be guessed at...

Best wishes from Riley.

| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.078 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site