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.
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
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.
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.