Bug 222251 - ps start time jitter
ps start time jitter
Product: Fedora
Classification: Fedora
Component: procps (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Smetana
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-01-10 21:58 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 3.2.7-9.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-26 09:16:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2007-01-10 21:58:37 EST
Description of problem:
When running ps repeatedly it is possible to observe jitter in the STIME field.

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

How reproducible:
Always, provided the planets are aligned correctly

Steps to Reproduce:
1. ps -ef
2. observe STIME column
Actual results:
STIME field sometimes appears to randomly change value

Expected results:
STIME field for a process should not change over time or invocations of ps

Additional info:
The STIME field is calculated from "time_of_boot + pp->start_time/Hertz" and
effectively "time_of_boot = time(NULL) - uptime(0, 0)".
The problem appears to be that uptime() is not synchronous with time(). It would
also seem that at some stage pp->start_time was secs since 1970 (which is what
code comments still say) but it is now jiffies since boot time. So in the
process of reading /proc/uptime and /proc/*/stat non-atomically there is going
to be a discrepancy.

Wouldn't it be a lot better if kernel recorded actual absolute start time? What
if timezone changes, or daylight saving begins, or clock gets adjusted for any
other reason?

Alternatively the kernel could record /proc/boottime (to match uptime) so that
programs like ps don't have to try and calculate it with non-atomic
Comment 1 Tomas Smetana 2007-04-25 07:51:42 EDT
I really don't know of any simple solution of this. Another related problem is
that /proc/uptime is not updated on suspended system. Then the STIME coloumn
reports totally wrong value.
Comment 2 Tomas Smetana 2007-04-26 09:16:59 EDT
There's no need to compute the boot time -- it's written in /proc/stat. So
substituting uptime by (time(0) - btime) should help.

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