Re: [gentoo-amd64] Re: hardware clock often doesn't sync to system on shutdown

[Thanasis]

on 09/14/2008 11:44 AM Duncan wrote the following:
> Thanasis <thanasis@××××××××××.org> posted 48CA0929.60003@××××××××××.org,
> excerpted below, on  Fri, 12 Sep 2008 09:16:09 +0300:
>
>
>> I have a laptop (Gateway T-1625), set up with ntpd to sync the system
>> time (with the "-s" option in /etc/conf.d/ntpd) to a local system of the
>> LAN.
>> What happens is tha although it syncs the system time successfully, it
>> often fails to sync the hardware clock during shutdown although I have
>> set CLOCK_SYSTOHC="yes" in /etc/conf.d/clock, and so I see those "One of
>> the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification
>> time in the future!" boot messages. Then I can confirm the difference in
>> time using the commands "date" and "hwclock --show" which shows the
>> difference, eg:
>>
>> # hwclock --show && date
>> Thu 11 Sep 2008 09:55:22 PM EEST  -0.228853 seconds
>> Fri Sep 12 08:58:30 EEST 2008
>>
>
> EEST = Eastern European Summer Time, UTC+300, correct?  (Just wikipediad
> it)
>
> Given the 11 hour time difference reported above, this may not be your
> problem, but here, I'm MST, (US Mountain Standard Time, UTC-700), and at
> one point I was having problems with a 14 hour difference because the
> system (clock init script? something anyway) was adjusting the wrong
> direction, UTC+700 instead of UTC-700.  Obviously, that created
> problems...
>
> So... check your time zone settings.
>
> You may also want to step thru the init script logically and figure out
> what command it's actually using (or add a set -x right before the
> hwclock call, and a set +x right after, so you get the line from bash,
> running the initscript manually to see what it spits out), then issue the
> same exact command on the command line, where you can see the error
> output if any.  I remember doing this while troubleshooting my problem
> (which eventually got fixed) here.
>
> FWIW I run ntp also, and have clock set to sync at shutdown.  I've not
> had any problems since whatever it was that time got fixed.  I'm still
> not sure exactly what was screwed up, but being 14 hours off until I got
> networking and started ntp wasn't fun, I'll tell you that!
>
> I also have the local clock set to local (UTC-700) time.  That's not
> recommended for those who have time changes twice a year (except for
> those dual booting MS whatever, since it only does local time, IIRC), but
> AZ is one of the states here in the US that doesn't, so I don't have to
> worry about it.
>
> So that's something else to consider.  You may have better luck toggling
> the system and hwclock to the other of UTC or local.  I was about to give
> up and switch to UTC here, just to see if it would work, when either
> something I did or a package update fixed it and it just started
> working... <shrug>
>
> Finally, since you run ntp, it's not really vital that you have the
> hwclock synced /exactly/ anyway.  Try setting your hardware clock from
> the BIOS... if it's off a few seconds, no biggee, the ntp sync with fix
> it.  You can then turn the shutdown sync off, if desired, and just let
> the hardware clock run on its own, updating it manually if it gets too
> far off.  By combining that with toggling UTC/local, and/or purposefully
> setting the hardware clock a few minutes ahead, you should be able to
> avoid the future filetime warnings, since the difference would be putting
> the filetimes in the past instead of the future.  Just don't get too
> carried away, because rc uses those filetimes to track whether it needs
> to recache its service dependencies, etc, and if you have the hwclock set
> too far ahead, it won't detect config changes you've made and end up
> using stale data.
>
>
Duncan,
Thanks to your guidance, I found out that I had a large "systematic 
drift rate" in /etc/adjtime file. This must have been the reason why the 
hwclock was set behind. So I've set the drift to zero (actually just 
deleted the file and let the system create a new one) and I hope things 
will be ok now. :-)