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

[Jon Severinsson]

Control: reassign -1 ntpdate
Control: retitle -1 ntpdate does not set the RTC when syncing the system clock

>> 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.

If the user sets or syncs the clock, it is indeed reasonable to expect it to 
persist, but the text you are quoting regards the case of a user *not* 
touching the clock in any way.

In that case the only difference between the system clock and the RTC is that 
they might tick at slightly different paces, and there is nothing to say that 
the (software) system clock had a more accurate pace than the (hardware) RTC, 
which is why systemd does not overwrite the RTC with the system clock at 
shutdown.

That said, anything that changes the system clock based on an authoritative 
source (eg user input or network sync, as opposed to drift calculation or 
other heuristics) should usually set both the system clock and RTC, as I agree 
that users shouldn't be expected to know about the difference.

> [ntp] will also open a daemon to let others sync with my machine, certainly
> not something I want.

By default ntp only listens on 127.0.0.1 (for control commands), and will not 
allow other systems to sync with it, so it is not as bad as you think.

In most cases a system that are connected to the Internet for any length of 
time (even if not constantly) should use a continuously syncing daemon like 
ntp (or the upcoming systemd-timesyncd) rather than a oneshot program like 
ntpdate, in order to *stay* synced while connected.

> Having around half the Debian systems (those where the RTC is behind the
> actual time) with this bug is certainly not an acceptable state.

Agreed.

> So how do you think this should be fixed? [...] I could see ntpdate updating
> the RTC after fetching the current time.

That would indeed be the proper fix, so reassigning this bug to ntpdate.

(The fact that hwclock has historically papered over this bug should not be 
used as an argument for forcing systemd to similarly paper over it, as bugs 
should generally be fixed at their source.)

Best regards
Jon Severinsson