On Sat, 2011-07-16 at 10:22 +0200, Per Jessen wrote:
Roger Oberholtzer wrote:
I am on a laptop that exhibits the problem. hwclock -r is showing the correct UTC time that I expect. The network is up via NetworkManager when I logged in graphically. The ntp that started when I booted is still running. But, alas, the time is incorrect. It can sit like this for hours, and the time will NEVER be corrected. Ever. Consistently.
All I have to do now is run 'rcntp restart', and time will be corrected.
Carlos explained this issue very well. Now you need to examine why your system clock is off by two(?) hours when it is started. (Two hours discrepancy is not an inaccuracy, it is a clock that has been wrongly set).
The two hours is because the hardware clock is set to UTC time. That is two hours from local time in Sweden. So one question I have that I have not brought up (isn't the current question enough to keep us busy? :) ) is why when ntp fails does the system seem to ignore the system timezone? I have been assuming that the system does in fact set the time according to the timezone (in the hwclock startup script). Then, when the ntp startup script is run, it does it's own thing which involves setting the time back to the hardware time, expecting to correct it when a time server is found. As no time server is found, step one of the ntp startup process is all that happens, leaving the time in the original hardware state.
I suspect it is that the ntp rc script is assuming that since it is set to start after networking, it can assume that access to time servers is available when it starts. Alas, when a network device starts some time afterward, this assumption is faulty.
The ntp init-script is not really intended to fix enormous hour-size gaps of time - on a normal startup the time offset of the local system might be measured in seconds, which ntp will then correct immediately provided a time source is available. If the time cannot be set, and the gap is 1000s or more, ntpd will exit immediately.
Once again, the difference between the hardware clock and local time is because the hardware clock is in UTC time. It is not really wrong. I would have thought that was the preferred method on Linux. Things like daylight savings time switching only happen if the hardware clock is in UTC time. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org