Description of problem: In /etc/rc.d/rc.sysinit it seems to be assumed that either the cmos clock is drift-free(!) or that /sbin/hwclock --hctosys adjusts for drift. However, the command does not (at least now) adjust the time from the cmos clock to account for drift. The manpage for hwclock recommends calling /sbin/hwclock --adjust before using --hctosys, presumably for exactly this reason, however the command is called in /etc/rc.d/rc.sysinit before the root fs is remounted rw, so calling /sbin/hwclock --adjust there would either fail or would cause clock corruption since the clock drift timestamp could not be written. Solution 1 would be to patch hwclock to perform drift calculations before setting the clock. Solution 2, which I assume is a lot easier, would be to call /sbin/hwclock --adjust before setting the system time from the clock, which means it would have to be done after remounting root. Not sure what this might break though. Also, if ntpd is being run, then the drift calculations are rendered useless by the final saving of system time in the shutdown script - there would need to be some sort of cooperation between ntp and the shutdown script to fix this though. Version-Release number of selected component (if applicable): Those in FC1.0 to 3.0, maybe earlier & later too. I think it used to work properly in RH6.0, but maybe I'm misremembering. How reproducible: 100%! Steps to Reproduce: 1. Have CMOS clock which drifts at a measurable rate. Use adjtimex to find cmos clock drift rate, set in /etc/adjtime. Set clock to right time. 2. Turn machine off for long enough to measure a second or 2 drift (2 days on my machine!). Boot. 3. $ hwclock ; date +%c%N (clocks show almost identical, incorrect times) $ hwclock --adjust. $ hwclock ; date +%c%N Notice that hwclock now shows correct time. Actual results: Frustrated user after carefully setting drift rates and still finding that the computer never tells the right time. - 5 mins our after 6 months. Used to be better than this! Expected results: With drift calcns used properly, system clock should only need milisecond slews from occasional ntp queries once a month, not 5 second jumps after only a week. Additional info:
We don't want to move the hwclock invocation to later, as that causes improper time and date stamps in logs, etc.
Not knowing much about the internals of the scripts, surely not much is going to get logged anywhere before root is mounted RW? I thought syslog applied the timestamps and that won't happen until way after root remount. Even if I'm wrong, I'd rather a couple of early boot-log lines get the wrong time than every log item wrong until the time gets corrected.
Created attachment 111709 [details] Apply drift calculations to hwclock I don't at all see why hwclock should ever NOT apply drift caclulations (assuming they are valid), so I've hacked it so it does. This almost certainly adds an extra delay before setting the clock so I'd not expect perfect accuracy, but I seriously doubt it'll ever be worse than not applying the drift calculations at all. Hopefully I got the signs right...
Created attachment 111710 [details] Apply drift calculations on running --hctosys I don't at all see why hwclock should ever NOT apply drift caclulations (assuming they are valid), so I've hacked it so it does. This almost certainly adds an extra delay before setting the clock so I'd not expect perfect accuracy, but I seriously doubt it'll ever be worse than not applying the drift calculations at all. Hopefully I got the signs right...
Created attachment 111711 [details] New option to hwclock to tell it to keep old drift rate If ntpd has been run long enough to tell the kernel that it's clock externally synchronised, then the cmos clock drift caclulations are by definition wrong. This patch lets, say, the ntpd or shutdown scripts record the return to an unsyncronised state.
Created attachment 111712 [details] New option to hwclock to tell it to keep old drift rate If ntpd has been run long enough to tell the kernel that it's clock externally synchronised, then the cmos clock drift caclulations are by definition wrong. This patch lets, say, the ntpd or shutdown scripts record the return to an unsyncronised state.
Please, send your patch to upstream developers. I would like to see this integrated by upstream rather then FC/RHEL specific patch. Thanks.
Closing per previous comment.