bogus create_time in LXC containers

[mbanck]

The patroni acceptance tests fail under LXC cause patroni checks the (process start) timestamp in a pid file against self.create_time, and the latter is reported as several days in the future (note that the two timestamps are swapped by error, I opened an issue for that):

2018-09-26 05:20:50,478 INFO: Process 7166 is not postmaster, too much difference between PID file start time 1538286721.13 and process start time 1537939195

Some digging and the fact that the autopkgtest on ci.debian.net is run in LXC containers turned up lxc/lxcfs#164 ("btime is not virtualized in /proc/stat") which sure sounds like the culprit, i.e. the btime that create_time uses as boot time/uptime for process creation time computation in https://github.com/giampaolo/psutil/blob/master/psutil/_pslinux.py#L1631 is bogus in this case.

[giampaolo]

Please try to be more clear about what the problem is and what you think psutil should do about it. Your bug report is a bit confusing.

[mbanck]

The problem is that in an LXC container, the SDATE field in /proc/[pid]/stat is relative to host uptime, while the btime field in /proc/stat is relative to container uptime (they virtualized /proc/stat but not each individual /proc/[pid]/stat). So psutil's create_time returns times from the future.

One thing which is not virtualized is the sysinfo() syscall (see e.g. https://stackoverflow.com/questions/42471475/fastest-way-to-get-system-uptime-in-python-in-linux?rq=1) so maybe psutil could either compute BOOT_TIME from that or, if that is not acceptable, check create_time against the current date and if its in the future, use sysinfo() to get the correct boot time.

[mbanck]

Actually, there's already a comment about this here:

https://github.com/giampaolo/psutil/blob/master/psutil/_psutil_linux.c#L262

[giampaolo]

Clear. Sounds reasonable.

[wiggin15]

You mentioned lxc/lxcfs#164, but it says there that they reverted btime virtualization in /proc/stat for exactly this reason (reverted in lxc/lxcfs@72dd97f). Only LXC 2.0.7 seems to be affected by incorrect btime.

[mbanck]

Right, I digged a bit deeper and found that in the meantime as well. Problem is that 2.0.7 got shipped in Debian stable (and so far has not been fixed, although I am working on it), so maybe it is still worth fixing? But it's true that this needs some backtracking.