Bug 132062 - The kernel's btime in /proc/stat decreases 1 second every 2 hours.
The kernel's btime in /proc/stat decreases 1 second every 2 hours.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Martuccelli
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-08 10:12 EDT by Jason Smith
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-05 14:52:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason Smith 2004-09-08 10:12:02 EDT
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.
Comment 1 Ernie Petrides 2004-09-08 15:56:45 EDT
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?
Comment 2 Jason Smith 2004-09-09 18:01:55 EDT
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
Comment 3 Eric Hagberg 2005-02-07 12:14:22 EST
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?
Comment 4 Eric Hagberg 2005-02-07 16:43:55 EST
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?
Comment 5 Jason Smith 2005-02-07 17:02:52 EST
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?
Comment 6 Peter Martuccelli 2006-01-05 14:52:36 EST
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.
Comment 7 Jason Smith 2006-01-06 12:02:33 EST
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.

Note You need to log in before you can comment on or make changes to this bug.