[systemd-devel] [PATCH][Resend][RFC] core: Fix wrong timestamps in rtc-in-local time mode.

[Lennart Poettering]

On Thu, 25.12.14 22:00, Chunhui He (hchunhui at mail.ustc.edu.cn) wrote:

Sorry for the late response, still busy processing all the queued
mails and patches...

> Thanks David! Yes, I missed Lennart's reply.
> 
> Thanks Lennart!
> Yes, I agree rtc-in-local-time is a compatibility hack.
> 
> But I think similar issues in other components is orthogonal to this bug.
> The key is that systemd records _inconsistent_ timestamps. It's surely a
> logic _error_ introduced in commit 3a170f3d3358135a39ac6eafe66f18aef0bd67d,
> even though this bug appears in "compatibility hack".
> 
> rtc-in-utc is orthogonal too. In contrast, using rtc-in-utc is a workaround
> in this situation. Since we provide the compatibility, we have to fix it.

Hmm, so you are saying there's a bug in rtc-in-utc behaviour here too?
Could you elaborate, please?

I mean, I think we should accept that wallclock time is not linear (I
mean, the fact that it isn't linear is acknowledged by the existance
of CLOCK_MONOTONIC...), and I think it's a really good idea to record
the kernel's notion of the wallclock time at the point some event
happened, even if it's likely to be incorrectly set. 

Note that we do a lot of things before the initial timewarp is done,
including loading of the SELinux policy. Given how time consuming
loading of SELinux policy is, and that it might result in log messages
on its own, we really should not confuse the user by reporting some
very selected early, specific events adjusted, while leaving the usual
events unadjusted... 

We are really interested in making logging timestamps relatable to
each other, regardless where they come from. This only works, if the
all sources use the unaltered kernel timestamps, so that everybody's
time axis makes a jump at the same time when the timewarp is first
enforced. Adjusting some logged timestamps but not others would be
really confusing...

I hope this makes any sense. But maybe I misunderstood what precsiely
you are actually intending to change with your patch?

Lennart

-- 
Lennart Poettering, Red Hat