Extra uptime entry generated for one reboot (power loss)
glmaster123 opened this issue · comments
Hello,
I am trying to use tuptime to monitor shutdown events due to power loss and I am having an issue where I see an extra uptime entry but I only turn on/off the machine once. In the following table tuptime -t ouput, each of the ~22/23 second entries do not make any sense. The others are valid according to my testing and the start up and shutdown times are correct. You can see for the incorrect entries, that the startup/shutdown times are within the previous valid start/shutdown ranges. Do you know of any way to fix this? My setup is Jetson Nano. Thank you in advance.
tuptime -t
nvidia@ESP-Interface:~$ tuptime -t
WARNING:root:Negative value registered at startup '4'
WARNING:root:Downtime '-234.78' reset to '0'
WARNING:root:Negative value registered at startup '8'
WARNING:root:Downtime '-88.72' reset to '0'
WARNING:root:Negative value registered at startup '10'
WARNING:root:Downtime '-218.97' reset to '0'
WARNING:root:Negative value registered at startup '12'
WARNING:root:Downtime '-1347.64' reset to '0'
No. Startup Date Uptime Shutdown Date End Downtime
1 03:21:13 PM 04/26/2021 48 seconds 03:22:01 PM 04/26/2021 BAD 1 minute and 36 seconds
2 03:23:37 PM 04/26/2021 40 minutes and 15 seconds 04:03:52 PM 04/26/2021 BAD 1 minute and 25 seconds
3 04:05:17 PM 04/26/2021 9 minutes and 45 seconds 04:15:02 PM 04/26/2021 BAD 2 minutes and 0 seconds
4 04:17:02 PM 04/26/2021 12 minutes and 59 seconds 04:30:01 PM 04/26/2021 BAD 0 seconds
5 04:26:06 PM 04/26/2021 22 seconds 04:26:28 PM 04/26/2021 BAD 7 minutes and 7 seconds
6 04:33:35 PM 04/26/2021 6 minutes and 27 seconds 04:40:02 PM 04/26/2021 BAD 2 minutes and 5 seconds
7 04:42:07 PM 04/26/2021 23 seconds 04:42:30 PM 04/26/2021 BAD 12 minutes and 31 seconds
8 04:55:01 PM 04/26/2021 10 minutes and 0 seconds 05:05:01 PM 04/26/2021 BAD 0 seconds
9 05:03:32 PM 04/26/2021 22 seconds 05:03:54 PM 04/26/2021 BAD 8 minutes and 12 seconds
10 05:12:06 PM 04/26/2021 37 minutes and 56 seconds 05:50:02 PM 04/26/2021 BAD 0 seconds
11 05:46:23 PM 04/26/2021 23 seconds 05:46:46 PM 04/26/2021 BAD 8 minutes and 30 seconds
12 05:55:16 PM 04/26/2021 14 hours, 14 minutes and 46 seconds 08:10:02 AM 04/27/2021 BAD 0 seconds
13 07:47:34 AM 04/27/2021 23 seconds 07:47:57 AM 04/27/2021 BAD 1 hour, 32 minutes and 25 seconds
14 09:20:22 AM 04/27/2021 23 minutes and 27 seconds
tuptime.service
Description=Tuptime service
After=time-sync.target
Wants=time-sync.target
[Service]
Type=oneshot
User=root
RemainAfterExit=true
ExecStartPre=/bin/sleep 15
ExecStart=/usr/bin/tuptime -x
ExecStop=/usr/bin/tuptime -xg
[Install]
WantedBy=basic.target
Quick response -> update to the latest version. Please, replace the file executable directly with this one, it'll run fine:
wget https://github.com/rfrail3/tuptime/raw/master/src/tuptime -o /usr/bin/tuptime
The reason why you're getting this warning with negative values are because the system clock is jumping backward, the time value received by Tuptime from Linux on two consecutive requests is lower. This behaviour seems extrange, but exists, and the last part of the following pharagrah of the tuptime-manual.txt have related information:
If the system starts with a incorrect datetime and some external time sync is
used, like ntpd or timesyncd, a few time after boot the startup datetime reported
by the system may change. This behaviour is also related with adjustments
performed by adjtime(3), systems running inside virtualized environments, servers
with high load or with high disk I/O, wrong computation of jiffies / HZ and the
problema of lost ticks.
Jetson Nano doesn't have a working RTC (like RaspberryPi) but in this device, it have the hardware but not the battery to support the time while the board is power off (info). Althought it doesn't seems your main problem, that can help in keep the time between reboots, specially for trust on clock just before startup. I encourage its use.
Besides of that, if the cpu is very busy executing blocking stuff, it can lost the computation of the clock interrupts, and the system clock could drift time until an NTP software fix it. This seems to be close to your case. Please, get some background ideas taking a look to the section "About sync date and time" on the manual
As you're trying to debug issues, for a narrow shutdown date close to the real one, I recommend a lower periodic schedule on /etc/cron.d/tuptime. You could change it to a minute (all with *).
About the recomendation of the update, older versions of Tuptime had the startup identify linked with the times reported by the system, since version 5, the boot_id value is used primary, so it's more robust.