Bug#755722: systemd: Warning on each reboot: Superblock last write time is in the future

[Ralf Jung]

Hi,

> Ralf Jung <post at ralfj.de> writes:
>>   $ sudo hwclock -r ; date                                                                                                                                                                                        
>>   Tue 22 Jul 2014 20:13:22 CEST  -0.235161 seconds                                                                                                                                                                                             
>>   Tue 22 Jul 20:14:53 CEST 2014
>>
>> The hardware clock is off by around 1.5 minutes. (Whatever hwclock
>> tries to tell me with that time delta, I don't know^^.)
> Install “ntp” and the problem will be fixed.

I already have "ntpdate" and KDE is set up to sync my clock via NTP.
That's working fine, "date" is accurate (As far as I recall, KDE uses
ntpdate to do this update).
According to the ntpdate description, this is exactly the tool I want
for a machine that doesn't have internet all the time, like my laptop.
It's nicely hooked into the if-up scripts.

> systemd intentionally does not sync the system clock to the hwclock, see
> http://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html

Weird. This is IMHO a regression, and a fairly subtle one as well.
I also don't see any good reasons for this, even after reading the mail
you linked to (quoting below - yes I am aware that it's not you who
wrote that, but I just absolutely cannot follow Lennart's arguments here).

> In general there's not really a
> reason to assume that the system clock was anymore correct than the RTC
> so it's probably a good idea to leave the RTC untouched.

I think that's just wrong. The system clock is the one users see, they
will change it when it's wrong or check whatever is necessary to
auto-update it. You cannot reasonably expect users to even know that any
other clock even exists.

> And if the
> user changes the system clock manually it's his duty to sync that
> through to the RTC, and if he doesn't then he probably has a reason
> to.

I'd argue, if he doesn't he probably doesn't know there's such a thing
as an "RTC".


So it seems ntp does some magic to trigger the writeback. It will also
open a daemon to let others sync with my machine, certainly not
something I want. I will try it, but I don't see how that's a proper fix
for the problem, it's more like a work-around (or systemd should
Recommend ntp).

>From all I know, ntp is not in a Debian default installation. Having
around half the Debian systems (those where the RTC is behind the actual
time) with this bug is certainly not an acceptable state (I hope we
agree on this). So how do you think this should be fixed? If you don't
want to deviate from upstream systemd (which I can understand), and
cannot convince Lennart to change his mind (which I'd be surprised to
see happening ;-), I could see ntpdate updating the RTC after fetching
the current time. That will still leave everybody using "date" to fix
his clock affected (or does date already trigger a writeback?).

Kind regards
Ralf