STARTTIME is incorrect in 2.2.0
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
htop (Ubuntu) |
Expired
|
Undecided
|
Unassigned |
Bug Description
I have several up-to-date instances of Ubuntu 20.04 and one of them consistently shows incorrect STARTTIME. The column often shows the same timestamp for most processes with only a handful of top level exceptions like /sbin/init and /lib/systemd/
In the same instance the old issue of process name not being completely refreshed is back. This is very noticeable with postrgesql processes that change process name according to the command they execute. E.g. when a process changes state from running a SELECT to idle the process name changes from SELECT to idleCT keeping the last 2 characters "CT" of SELECT.
As a reference top when run with -o lstart produces correct process start timestamp.
This issue is discussed here: https:/
Thanks for taking the time to report this bug and trying to make Ubuntu better.
Since you mentioned this behavior was fixed in version 3.0.2 the next step is to identify the fix so we can cherry-pick it. We do not introduce new upstream releases to a stable Ubuntu release.
With that in mind, I quickly checked for commit messages referring to STARTTIME after the release of 2.2.0 (the version we have in Focal) but I am not sure whether what I found is useful in this case. Maybe it is if you did remount /proc in the buggy instance.
commit bd1d719a61bbca1 6f7dd373dcc1e23 4f3c8ea09b
Author: Shawn Landden <email address hidden>
Date: Sat Aug 18 21:29:03 2018 -0700
Linux: add process->starttime and use it for STARTTIME column (#700)
this way a remount of /proc will not reset starttimes
and we can also see startup times for processes started before the mount
of /proc
also record btime (boot time in seconds since epoch) as Linux semi-global
I'd kindly ask you to check if you can find the fix in the upstream tree for this issue you are facing. If we have the commit(s) needed we will gladly fix it in Focal.
I was not able to reproduce your issue locally, htop is working very well for me. Therefore, I am marking this bug as Incomplete because I cannot verify it. However, in case you find the fix please add a comment here with the proper links and mark it as New again, so the team can revisit it.