Bug 125372

Summary:	ps gives incorrect time for process start
Product:	[Fedora] Fedora	Reporter:	Peter Hunter <peter.hunter>
Component:	procps	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-30 19:09:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Peter Hunter 2004-06-05 10:49:52 UTC

Description of problem:
ps gives time in the future for recently-started processes. Time as given by 'date' is 
correct as is the time shown by 'w'. Times given for recently-started processes by ps are 5 
mins in the future.

Version-Release number of selected component (if applicable):
3.2.0-1.1

How reproducible:
Always

Steps to Reproduce:
1. Start a process
2. Do a ps u
3. Check system clock using 'date'

Actual Results:  START time given will be in the future by about 5 mins

Expected Results:  Time given by ps u as the start time and time given by date roughly the 
same.

Comment 1 Daniel Walsh 2004-06-09 18:36:47 UTC

Seems to be working here.
 sh -x t.sh
+ date
Wed Jun  9 14:29:57 EDT 2004
+ xterm
+ ps u
+ grep xterm
root     27278  0.0  0.4  8224 2148 pts/44   S+   14:29   0:00 xterm
+ date
Wed Jun  9 14:29:57 EDT 2004

Comment 2 Peter Hunter 2004-06-10 08:16:09 UTC

OK - I am really puzzled. It's now working for me too. Could it have been caused by DJB's 
clockspeed program? Perhaps it skews two different internal representations of what the 
current time is? I don't know how this works so I am at a loss to know how date and ps can 
report different times.

Comment 3 Albert Cahalan 2004-07-20 17:24:58 UTC

Try the 2.6.7 kernel or newer. (2.6.8-rc2 is out now)

There have been multiple problems caused by HZ not
being an integer. Rather than use a PLL to correct
this as BSD does, Linux tries to get by with some
code thinking HZ is 1000 and some other code thinking
that HZ is, for example, 999.943812 or 1000.0139804
instead. This discrepancy leads to inconsistant data
in the /proc filesystem.

(this is barely related to the HZ vs. USER_HZ issue
if at all; it's a nanoseconds-per-jiffy problem)

Expect to be fixing and re-fixing this bug forever,
assuming Linux never adopts a PLL like BSD uses.