From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040803 Description of problem: I have a system where the kernel's boot time from /proc/stat appears to decrease by one second every 2 hours. I first noticed this when I saw the start time of some long running processes decreasing, which apparently comes from the processes start time in jiffies relative to the boot time, plus btime. I checked another system and see the opposite behavior, btime appears to be increasing, but at a slower rate, about 1 second every 6 hours. I read somewhere that the kernel calculates the btime from the current gettimeofday minus the jiffies since boot converted to seconds. Is this still true? Is the jiffies value changing then? Both computers have their clocks synchronized with ntp and do currently have the same stratum 1 server: NAVOBS1.MIT.EDU. Version-Release number of selected component (if applicable): kernel-2.4.21-15.0.4.EL How reproducible: Always Steps to Reproduce: Example command: # while [ "1" ]; do grep btime /proc/stat ; sleep 7200 ; done Actual Results: Decreases by one second every two hours: btime 1093531025 btime 1093531024 btime 1093531023 btime 1093531022 btime 1093531021 btime 1093531020 btime 1093531019 btime 1093531018 btime 1093531017 ....... Expected Results: Should give the same result every time: btime 1093531025 btime 1093531025 ...... Additional info: All of my systems have their clocks synchronized with ntp.
Hello, Jason. Solely as an experiment, could you please try disabling ntp for several hours on the machine whose btime drifts backwards by a second every two hours? Does the btime stabilize in this scenario?
I tried turning off ntpd and checking btime on both of the systems I did before, and see the same exact behavior. On the one that goes backward I still see: # while [ "1" ]; do grep btime /proc/stat ; sleep 7200 ; done btime 1094744871 btime 1094744870 btime 1094744869 btime 1094744868 and on the one that goes forward slowly I still see: # while [ "1" ]; do grep btime /proc/stat ; sleep 7200 ; done btime 1094661135 btime 1094661135 btime 1094661136 btime 1094661136 btime 1094661136 btime 1094661137 NOTE: After testing this I re-synchronized the clocks with ntpdate, they had only drifted by less than 1 tenth of a second. ~Jason
We're seeing similar behavior here. I read another BZ issue (127302) that seems to indicate the problem is fixed in RHEL4-era kernels. What's the chance this'll be fixed for an RHEL3 kernel?
Actually, I'm not seeing this on current RHEL3 machines (w/ the Update 4 kernel). Maybe this was fixed but it's not clearly mentioned in the changelog?
I am still seeing this with the latest kernel, 2.4.21-27.0.2.ELsmp. Since the kernel's btime is not a static number (I believe that it is calculated by subtracting the kernel's uptime from the current time), I guess this indicates a slight skew in the kernel's uptime value. Could this be a hardware issue, and if ntpd is running, it will keep adjusting the kernel's clock frequency to keep its clock accurate, which then skews the kernel's uptime? Maybe this is caused by an inaccurate clock interrupt generated by some motherboards. Why is the btime not a static number anyway?
RHEL3 is entering maintenance mode. This issue will not be considered for resolution in RHEL3. You can try running the U7 kernel which is in beta at this time, (FWIW - I did not see any patches that would affect your issue with btime output going back to the U4 development timeframe). Closing this issue out as wontfix.
FYI, I tested this on a RHEL4 system and it doesn't appear to exhibit this btime drift problem, at least after about 24 hours. I also found an old RH-8.0 system that we still had around and found that it also exhibited a slowly drifting btime, about 8 seconds in 24 hours. The root problem might have been something more general to all 2.4 kernels, which is not present in the more recent 2.6 series.