needs-restarting: Get process start time by /proc/pid mtime

[evan-goode]

The previous method of getting a process's start time was to add the boot time detected by ProcessStart.get_boot_time to the process's starttime:

man 5 proc

              (22) starttime  %llu
                     The time the process started after system boot.
                     Before Linux 2.6, this value was expressed in
                     jiffies.  Since Linux 2.6, the value is expressed
                     in clock ticks (divide by sysconf(_SC_CLK_TCK)).

                     The format for this field was %lu before Linux 2.6.

But the starttime is relative to the kernel start time, which does not always match the result of ProcessStart.get_boot_time.

A simple solution might be to use the mtime of /proc/pid instead. The mtime is set to the current wall clock time when the process is started, so it should be correct for every process except PID 1, where the correct time may not yet be known.

For https://issues.redhat.com/browse/RHEL-39775.

[ppisar]

This patch avoids the wrong math (adding apples to oranges). That's good. However, I don't know whether st_mtime of /proc/$PID directory has the semantics (a start time of the process) you use here. I found it nowhere documented.

I guess procfs driver simply adds starttime of /proc/$PID/stat to btime of /proc/stat when asked by stat() on /proc/$PID. We would have to verify it somewhere (read Linux code, or ask a Linux maintainer). Or at least experimentally verify what happens when kernel is instructed to change a time zone, to change a system clock from a user space (date --set), and to change a system clock from RTC driver on boot.

[ppisar]

I briefly looked into Linux sources. I was unable to find where st_mtime of /proc/$PID inodes is set. Searching the Internet I found that the many years ago the time changed with each open of the file. Later the modification time was possible to change, e.g. with touch tool. Now kernel rejects changing the time with ENOPERM.

So it's quite possible that st_mtime of /proc/$PID now indeed something means. But what exactly, I'm not sure. Maybe it reports when the process entry was created in the running kernel. That should match when the process was created. But does hold e.g. after resuming from a suspend to disk? I'm not sure.

I checked what ps(1) of procps-ng-4.0.4 (ps -o start) does: It adds starttime of /proc/$PID/stat to btime of /proc/stat. I would rather implement it like that than relying on the undocumented st_mtime od /proc/$PID.

[evan-goode]

I briefly looked into Linux sources. I was unable to find where st_mtime of /proc/$PID inodes is set. Searching the Internet I found that the many years ago the time changed with each open of the file. Later the modification time was possible to change, e.g. with touch tool. Now kernel rejects changing the time with ENOPERM.

So it's quite possible that st_mtime of /proc/$PID now indeed something means. But what exactly, I'm not sure. Maybe it reports when the process entry was created in the running kernel. That should match when the process was created. But does hold e.g. after resuming from a suspend to disk? I'm not sure.

From my testing, the mtime of /proc/pid stays the same after changing the system clock, which is the behavior we want. But yes, it's not well-defined behavior and I didn't test some of the edge cases such as hibernation or booting with/without RTC. I am fine to close this in favor of #537.

I checked what ps(1) of procps-ng-4.0.4 (ps -o start) does: It adds starttime of /proc/$PID/stat to btime of /proc/stat. I would rather implement it like that than relying on the undocumented st_mtime od /proc/$PID.

That's essentially the old behavior of needs-restarting, and it works unless the correct time is not known when the btime of /proc/stat is set.