Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31674 - [systemd] add hwclock.service

Attached to Project: Arch Linux
Opened by Davorin Učakar (phantom) - Monday, 24 September 2012, 16:55 GMT
Last edited by Dave Reisner (falconindy) - Monday, 15 October 2012, 23:21 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


I see many people have problems with hw clock not synchronising to system clock on shutdown, which results in wrong time on next boot until time gets synchronised again. Intscripts have `hwclock` script for this purpose.

I propose adding a unit `/usr/lib/systemd/system/hwclock.service`:

Description=Synchronise Hardware Clock to System Clock

ExecStart=/sbin/hwclock --systohc


to either util-linux or systemd package.
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 15 October 2012, 23:21 GMT
Reason for closing:  Won't implement
Comment by Dave Reisner (falconindy) - Monday, 24 September 2012, 17:08 GMT
Perhaps you could point out these "many people". I'm very much against adding something like this. Why would the system time be trustworthy but not the hwclock? If you have time problems, you should be using ntpd, particularly with the 11 minute mode.
Comment by Tom Gundersen (tomegun) - Wednesday, 26 September 2012, 10:45 GMT
In case using ntp is not an option (no internet connection), then there might be a case for adjusting the RTC based on a known drift-rate (which hwclock will calculate if you set the correct time manually at least twice). However, we should then be using --adjust, not --systohc.

That said, I think it is extremely unlikely to get this right (setting the time manually correctly with enough precission is problematic, the other problem is the coarseness of --adjust). A better solution is to use chrony which knows how to deal with the RTC in the absence of NTP and which is much more likely to get it right than any hack we can cook up (the only reason I kept the hwclock "daemon" as part of initscripts is so that we would not be any worse than we used to be, but should I have done it from scratch I would not have included it at all.