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): procps-3.2.7-8 How reproducible: Always, provided the planets are aligned correctly Steps to Reproduce: 1. ps -ef 2. observe STIME column 3. 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 time(NULL)-[/proc/uptime]
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.
There's no need to compute the boot time -- it's written in /proc/stat. So substituting uptime by (time(0) - btime) should help.