-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uptime can jump when date is adjusted for devices without RTC #837
Comments
By the way, reading /proc/uptime yields the correct uptime value (as seen in the telegraf bug), so the kernel has a way to differentiate uptime and clock time somehow. |
@Gui13 As refer to your issue, the uptime method computes with a diff from boot time to now. The result of |
Nobody got news about that ? |
Ok that was a bit hash. Would you be open to a PR that fixes this issue ? |
Sorry, forgot to reply to this issue, but I was fearing we would have a similar side effect as described in giampaolo/psutil#658 (comment), for process creation time, which is used in IsRunningWithContext (psutil checks if this is the same process before terminating it and some other functions, this is not the case for gopsutil, for the moment). What I fear is that process.IsRunning() would return false if called after ntpd adjusts the clock, for all processes, if NewProcess() is called before the clock is adjusted. I have an old Raspberry Pi for testing this, if I disable ntpd service and only launch it manually, I should be able to reproduce according to your report. |
If you need me to test something, I have many RPis laying around. |
Do not cache boot time for linux. Fix #837
Describe the bug
Related to influxdata/telegraf#7018
When a device starts at a wrong date (say epoch, or another more recent date reported by fake_hwclock for instance), and the date is later adjusted to the real one with NTP, gopsutil starts reporting wrong uptime.
To Reproduce
Expected behavior
Do not use a differential computation for linux devices, maybe prefer parsing the /proc/uptime ?
Or at least try to detect large time slippage and reset the boot time ?
Environment (please complete the following information):
Additional context
Device has no RTC (Raspberry Pi 3 A+)
The text was updated successfully, but these errors were encountered: