[arch-general] apcupsd or rtkit - Caused time to go haywire on shutdown/reboot??

[David C. Rankin]

On 10/18/2011 11:55 AM, David C. Rankin wrote:
> Guys,
>
> Here is one for the brain-trust to consider. Something totally screwed up the
> time on my computer during an apcupsd commanded shutdown and the subsequent
> reboot resulting in a 479 Minute time disparity. I don't think this was
> handled on the first reboot after the power outage because after reboot, I
> worked for 20-30 minutes before the OS imploded rebooted automatically. I
> suspect the time discrepancy somehow carried through the boot and went along
> until some kernel mechanism totally went bonkers and shut the system down.
<snip>

> I don't have a clue what could have caused this time shift unless it was some
> spurious voltage issue. If not, then something is definitely funny with the
> time handling in either apcupsd or rtkit.
>
> What say the experts, problem or just weird voltage induced time skew?
>
>

   I think I have found part of the problem, but I cannot explain why the 
hwclock wasn't in sync with the sysclock. The box has now rebooted 4 more 
times, each time there is a time discrepancy of ~479 minutes.

[15:06 providence:/home/david] # grep disparity /var/log/everything.log
Oct 18 09:44:01 providence crond[953]: time disparity of -478 minutes detected
Oct 18 11:19:01 providence crond[978]: time disparity of -479 minutes detected
Oct 18 12:32:00 providence crond[1180]: time disparity of -479 minutes detected
Oct 18 12:42:00 providence crond[958]: time disparity of -479 minutes detected

   hwclock was way out:

[14:44 providence:/home/david] # hwclock -r
Tue 18 Oct 2011 10:44:19 PM CDT  -0.436795 seconds

   huh???

[14:44 providence:/home/david] # hwclock -w
[14:44 providence:/home/david] # hwclock -r
Tue 18 Oct 2011 02:44:52 PM CDT  -0.578618 seconds

   I don't recall the specifics, but I recall a discussion about a change in 
the way the OS keeps the hwclock in sync. I could be way off, but doesn't Arch 
maintain the hwclock with --systohc?

   With ntp running the sysclock was always correct after it synced, but for 
some reason, the hwclock had drifted out of sync by this much? Granted, this 
box usually runs from kernel update to kernel update without a reboot, but 
still is it normal to accumulate that much hwclock drift?

   I have checked 5 other Arch boxes and 4 were fine, but I have found another 
with a hwclock issue:

date && sudo hwclock -r
Tue Oct 18 14:58:24 CDT 2011
Tue Oct 18 23:58:00 2011  -0.438598 seconds

   Of the 6 boxes checked, 3 were Dell's and 2 out of 3 Dells had the hardware 
clock skew. I don't know what to make of it. Bad hardware? Anybody else seeing 
anything like this?

   Sorry for the noise, but if this is something other than an "idiot, check 
your hwclock in the BIOS issue.." I would welcome any other thoughts or 
proposed checks. Thanks.

-- 
David C. Rankin, J.D.,P.E.