On Tue, 19 Jul 2005, Jan-Benedict Glaw wrote: > > Well, `hwclock' should normally be used to update the RTC every time > > after a manual system clock update. > > Which of course should only be done once. Ever :) Well, depending on whether the system is networked or not. If it is, it's not needed at all as you fetch the initial setting over NTP, too. If it's not, then unfortunately it's needed every time you notice the clock has skewed too much. > > Note that ntpd only updates minutes and seconds and then only if the > > difference is small -- to account for the existence of time zones and a > > system-specific relation between the time recoreded by the system and one > > handled by the RTC. Also the feature is broken by design -- ntpd > > shouldn't do that at all in principle and in practice it leads to the > > system time being corrupted on some machines using an RTC interrupt for > > the system timer tick. > > Aren't we expected to keep UTC time inside the HW clock? So there's no It's a good idea, but whether it's feasible or not is unfortunately system-specific. > problem with timezones. Also, if your timer interrupt source it that > broken that ntpd cannot track it, then you're having more servere > problems... Huh? The time source is correct if let to run freely, but modifying the time stored in RTC may disturb it. This is e.g. the case with the Motorola MC146818 and its clones which are rather common chips -- any system using their periodic interrupt for the system clock tick suffers from this problem. > > > distributions seem to also update the HW clock at system shutdown time. > > > > Which is where it should really happen. > > I disagree. IFF there's a known good time, it's acceptable to write it > into a backing HW clock. In case there isn't (any longer), it's probably > better to not write to the HW clock at all. Probably it's contents is > better than a wrongly manually adjusted local date setting... Something has to preserve the clock across reboots and power-offs. Which of the sources is to be trusted more is a matter of a local policy and neither the kernel nor tools should force any particular one. > I do trust ntpd, but do I trust someone who looks at it's watch? Well, I do trust myself ultimately... > > > So the correct solution to your problem is to either shutdown once > > > (workaround) or keep ntpd running (the solution[tm]). > > > > I think you've got the figures reversed (well, it's useful to have ntpd > > running, but it should not fiddle with the RTC). > > Well, I stated my oppinion. Maybe ntpd shouldn't set the clock (or make > the kernel set it internally), but for sure I don't want the HW clock > being set by hand (except very first power-up of the system) and by no > means if local time came up from a manual process. If ntpd has been running with a good reference it must have disciplined the system clock, so it should have a smaller drift than the RTC. So it should be safe to store the former into the latter at a shutdown (but that's a policy). Otherwise nothing can be told about both clocks and the system's administrator should decide. In the end I think the decision should be left up to the administrator in all cases. Maciej
