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 _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
