rfmoz / tuptime Goto Github PK

would you be interested in a code review? i have a few suggestions of improvements that could be done to the code...

My team is creating a distribution that will include the tuptime package. We found that when we install our distribution image, tuptime reports the amount of time that our distribution image has been live (we occasionally install the image and modify it while it is running, then recreate it).

I want our images to start with tuptime at 0 each time they get installed. What is the correct way to reset tuptime back to 0?

After a normal startup, with a downtime of various days, Tuptime register the previous downtime as current uptime:

# tuptime -t
...
59   11:11:39 05/11/23          9m 48s   11:21:27 05/11/23   OK                  0s
60   11:21:27 05/11/23   34d 3h 4m 25s  

Inspecting the journal -b of the system reports this time jumps. Take into account that the current date is 2023-12-09:

-- Journal begins at Fri 2021-12-10 08:01:03 CET, ends at Sat 2023-12-09 14:23:41 CET. --
jun 18 16:55:54 host1 kernel: Linux version 5.10.0-8-amd64 ([email protected]) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03)
...
jun 18 16:55:56 host1 systemd-timesyncd[450]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sun 2023-11-05 11:21:28 CET
nov 05 11:21:28 host1 kernel: usb 5-2: New USB device found, idVendor=03f0, idProduct=2a41, bcdDevice= 1.00
...
nov 05 11:21:28 host1 systemd[1]: Starting Tuptime service...
...
nov 05 11:21:29 host1 systemd[1]: Finished Tuptime service.
...
nov 05 11:21:43 host1 at-spi-bus-launcher[775]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
dic 09 14:02:12 host1 systemd-timesyncd[450]: Initial synchronization to time server 162.159.200.1:123 (2.debian.pool.ntp.org).

Hi,

Could someone help with how long the tuptime will persist? Is there any retention period?

Regards
Kumar

Hello!

I think that a stateful call to -g is not actually required.

Whether the previous shutdown was graceful or not can be decided by

if [[ x"$(last -xn2 shutdown reboot | head -n 2 | awk '{print $1;}' | tr -d '\n')" == x"rebootshutdown" ]]

or something like that.
c.f. https://access.redhat.com/articles/2642741

The line above should also work on openbsd, with rebootshutdown replaced with shutdownreboot, or something like that.

Hi i really like this tool!!!
I fix the issue on Rpi that shows shutdown time in years! Now i want to ask if is possible to fix (or it is normal) the problem of shows every reboot as bad shutdown.

I have an update script run by crontab every 10 days:

#!/bin/bash -e

TODAY=$(date +"%d/%m/%Y %T")
echo ""
echo "###"
echo "### Aggiornamento AVVIATO"
echo "###"
echo "### Ora di inizio: "
echo "### "$TODAY""
echo "###"
echo ""

/usr/bin/sudo apt-get update

echo ""

/usr/bin/sudo apt-get -y dist-upgrade

echo ""

#/usr/bin/sudo rpi-update
/usr/bin/sudo tuptime

echo ""

TODAY2=$(date +"%d/%m/%Y %T")
echo ""
echo "###"
echo "### Aggiornamento COMPLETATO"
echo "###"
echo "### Ora di fine: "
echo "### "$TODAY2""
echo "###"
echo ""

/usr/bin/sudo shutdown -r now

i use the calling /usr/bin/sudo tuptime because i send via mail the output of entire script to a log file.

I've been going through the Fedora package review process and should shortly have tuptime available as part of the various Fedora and EPEL distributions (see https://bugzilla.redhat.com/show_bug.cgi?id=2007918 for more details).

However the question has been raised that there is currently no %check section (it is optional anyway) and what can be done about it? Is there any suitable testing that could be done?

System ubuntu20.04LTS
My tuptime is installed by https://git.io/tuptime-install.sh
Now I want to uninstall it, how can I do it?

The function "sanitize" is not used anywhere and can be removed.

I made a change in the way tuptime is installed in the Debian package. I made it be installed in /usr/sbin instead of /usr/bin. This is because tuptime is expected to be ran as root right now (see #13 for that as well). This follows the FHS standard (see man hier) but it breaks the systemd startup script, a bug that was reported in the Debian BTS in https://bugs.debian.org/806380.

Now, there are two ways to fix this:

• patch the debian package to change the systemd unit file
• install the script in /usr/bin instead

I would rather patch the systemd unit file, but if #13 is going to be fixed soon, it would make more sense to install the script in /usr/bin. Furthermore, it would prefer to avoid diverging from upstream as we wish to handover package management to upstream.

So could we switch to /usr/bin all over?

Hello,
Thanks for the tool, I wouldn't have an idea how to collect all this information.

I'm running it without issues on Ubuntu. However on OSX it's not possible as you can't create a crontab as root on OSX it seems as I tried to do it for another reason. It has to be done in a different way see here:

https://ampedup.wordpress.com/2017/09/12/crontab-not-working-in-macos-sierra/

Trying to install tuptime on my debian 10 (buster) machine using the install script.
I get this error:

++ Tuptime installation script ++

+ Getting source tar file
  [OK]
+ Copying files
  [OK]
+ Creating Tuptime execution user '_tuptime'
useradd: Benutzer »_tuptime« existiert bereits
  [OK]
+ Creating Tuptime db
  [OK]
+ Setting Tuptime db ownership
  [OK]
+ Executing Tuptime with '_tuptime' user for testing
  [OK]
+ Copying Systemd file
Synchronizing state of tuptime.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable tuptime
Failed to enable unit: Unit file /etc/systemd/system/tuptime.service is masked.

Same error when trying to enable it manually using systemd

systemctl start tuptime.service
Failed to start tuptime.service: Unit tuptime.service is masked

ls /etc/systemd/system/tuptime.service -hal
lrwxrwxrwx 1 root root 9 Apr 24 21:37 /etc/systemd/system/tuptime.service -> /dev/null

Python 3.7

Any help appreciated. Thank you!

hi!

first off, congratulations: your package will probable be shipped in the next debian release, Debian "stretch" 9. :)

according to the package tracker, there are lintian errors with the debian package. it seems we are missing a dependency on lsb-base. the details of this issue are here, basically you just need to add lsb-base (>= 3.0-6) to the Depends line.

i mention this as a bug report instead of doing a pull request so we make sure we still have the sponsorship workflow working in here, and that you are familiar with the package tracker.

let me know if you have any questions!

i noticed that, in the debian package, there is a manpage, and that is great! however, it seems to be missing from the source distribution. i added it back to the debian package, but it would be nice to have the source of the manpage available in the git repo and source distribution.

Hi All,

Good Day!

The tuptime shows wrong downtime around 1hr 21 min while the server up within minutes as per audit logs.Could someone help on this?

No. Startup T. Uptime Shutdown T. End Downtime

1 03:11:16 PM 03/12/2022 46d 21h 44m 49s 12:56:05 PM 04/28/2022 BAD 1h 21m 10s
2 02:17:15 PM 04/28/2022 22h 33m 59s

Audit logs:

type=SYSTEM_SHUTDOWN msg=audit(04/28/2022 14:16:52.959:968962) : pid=189010 uid=root auid=unset ses=unset msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

type=SYSTEM_BOOT msg=audit(04/28/2022 14:17:25.947:168) : pid=1238 uid=root auid=unset ses=unset msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

Regards
Kumar

I see where the largest and shortest up/down times got removed in version 5, but what was the reasoning? Are there plans to add it back in? I love that metric!

Hi @rfrail3 first try tuptime-plot1.py on a new computer got below error:

$ python tuptime-plot1.py -f ~/tuptime/tuptime.db
Default end:    now
Default begin:  since 7 days ago
Begin datetime: 22-Nov-2021 00:00:00
End datetime:   29-Nov-2021 23:59:59
Ranges on list: 8
0 range --->    0 events
1 range --->    0 events
2 range --->    0 events
3 range --->    0 events
4 range --->    0 events
5 range --->    0 events
6 range --->    1 events
7 range --->    0 events
Ranges got:     8
Traceback (most recent call last):
  File "tuptime-plot1.py", line 291, in <module>
    main()
  File "tuptime-plot1.py", line 231, in main
    days['up'].append(i[0])
IndexError: list index out of range

and tuptime.db is in below zip file:

tuptime.zip

Hi, I'm trying to run the dbcheck script, but I'm getting the following error:

  File "/home/USER/Downloads/tuptime_dbcheck.py", line 72
    <title>tuptime/tuptime_dbcheck.py at master · rfmoz/tuptime · GitHub</title>
                                                ^
SyntaxError: invalid character '·' (U+00B7)

I'm interested in finding the uptime since the most recent non-graceful shutdown. My systems do automated regular reboots, so any uptime since a non-graceful shutdown would be my "graceful uptime".

$ tuptime --table | grep --after-context 1 BAD | grep -v BAD  | tail -1
  3   20:59:06 21.02.2024    7m 31s   21:06:37 21.02.2024   OK         16s

Returns the first boot after the most recent non-graceful shutdown, which can in turn be used for the --since option:

$ tuptime --since "$(tuptime --table | grep --after-context 1 BAD | grep -v BAD  | tail -1 | awk '{print $1}')"
System startups: 	2  since  20:59:06 21.02.2024
System shutdowns: 	1 ok  +  0 bad
System life: 	        19m 56s

Longest uptime: 	12m 9s  from  21:06:53 21.02.2024
Average uptime: 	9m 50s
System uptime: 	        98.66%  =  19m 40s

Longest downtime: 	16s  from  21:06:37 21.02.2024
Average downtime: 	16s
System downtime: 	1.34%  =  16s

Current uptime: 	12m 9s  since  21:06:53 21.02.2024

I personally think that this concept of "graceful uptime" would fit perfectly into tuptime's default output, but a new option along the lines of --since-non-graceful, limiting the view to start at the first boot since the most recent non-graceful shutdown, would be just as fine.

Does any of this make sense? :-)

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

root@raspbx:~/tuptime# tuptime -l
Startup: 1 at 15:48:11 08/05/17
Uptime: -48 years, 225 days, 11 hours, 12 minutes and 19 seconds
Shutdown: BAD at 03:00:30 01/01/70
Downtime: 47 years, 139 days, 14 hours, 59 minutes and 5 seconds

Startup: 2 at 17:59:35 08/05/17
Uptime: -48 years, 225 days, 9 hours, 0 minutes and 56 seconds
Shutdown: BAD at 03:00:31 01/01/70
Downtime: 47 years, 139 days, 16 hours, 17 minutes and 55 seconds

Startup: 3 at 19:18:26 08/05/17
Uptime: 36 minutes and 59 seconds
Shutdown: BAD at 19:55:25 08/05/17
Downtime: 4 minutes and 16 seconds

Startup: 4 at 19:59:41 08/05/17
Uptime: -48 years, 225 days, 7 hours, 0 minutes and 50 seconds
Shutdown: BAD at 03:00:31 01/01/70
Downtime: 47 years, 139 days, 17 hours, 11 minutes and 39 seconds

Startup: 5 at 20:12:10 08/05/17
Uptime: -48 years, 225 days, 6 hours, 48 minutes and 19 seconds
Shutdown: BAD at 03:00:29 01/01/70
Downtime: 47 years, 139 days, 17 hours, 41 minutes and 30 seconds

Startup: 6 at 20:41:59 08/05/17
Uptime: -48 years, 225 days, 6 hours, 18 minutes and 32 seconds
Shutdown: BAD at 03:00:31 01/01/70
Downtime: 47 years, 139 days, 19 hours, 22 minutes and 56 seconds

Startup: 7 at 22:23:27 08/05/17
Uptime: -48 years, 225 days, 4 hours, 37 minutes and 0 seconds
Shutdown: BAD at 03:00:27 01/01/70
Downtime: 47 years, 139 days, 20 hours, 4 minutes and 45 seconds

Startup: 8 at 23:05:12 08/05/17
Uptime: -48 years, 225 days, 3 hours, 55 minutes and 16 seconds
Shutdown: BAD at 03:00:28 01/01/70
Downtime: 47 years, 139 days, 21 hours, 0 minutes and 43 seconds

Startup: 9 at 00:01:11 09/05/17
Uptime: -48 years, 225 days, 2 hours, 59 minutes and 21 seconds
Shutdown: BAD at 03:00:32 01/01/70
Downtime: 47 years, 140 days, 5 hours, 55 minutes and 14 seconds

Startup: 10 at 08:55:46 09/05/17
Uptime: -48 years, 224 days, 18 hours, 4 minutes and 45 seconds
Shutdown: BAD at 03:00:31 01/01/70
Downtime: 47 years, 140 days, 9 hours, 30 minutes and 12 seconds

Startup: 11 at 12:30:43 09/05/17
Uptime: -48 years, 224 days, 14 hours, 29 minutes and 48 seconds
Shutdown: BAD at 03:00:31 01/01/70
Downtime: 47 years, 140 days, 10 hours, 51 minutes and 45 seconds

Startup: 12 at 13:52:16 09/05/17
Uptime: -48 years, 224 days, 13 hours, 9 minutes and 7 seconds
Shutdown: BAD at 03:01:23 01/01/70
Downtime: 47 years, 140 days, 11 hours, 47 minutes and 8 seconds

Startup: 13 at 14:48:31 09/05/17
Uptime: -48 years, 224 days, 12 hours, 12 minutes and 50 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 140 days, 12 hours, 16 minutes and 6 seconds

Startup: 14 at 15:17:27 09/05/17
Uptime: -48 years, 224 days, 11 hours, 43 minutes and 52 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 12 hours, 28 minutes and 42 seconds

Startup: 15 at 15:30:01 09/05/17
Uptime: -48 years, 224 days, 11 hours, 31 minutes and 18 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 12 hours, 38 minutes and 41 seconds

Startup: 16 at 15:40:00 09/05/17
Uptime: -48 years, 224 days, 11 hours, 21 minutes and 20 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 140 days, 12 hours, 45 minutes and 33 seconds

Startup: 17 at 15:46:53 09/05/17
Uptime: -48 years, 224 days, 11 hours, 14 minutes and 26 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 12 hours, 58 minutes and 23 seconds

Startup: 18 at 15:59:42 09/05/17
Uptime: -48 years, 224 days, 11 hours, 0 minutes and 50 seconds
Shutdown: BAD at 03:00:32 01/01/70
Downtime: 47 years, 140 days, 13 hours, 31 minutes and 5 seconds

Startup: 19 at 16:31:37 09/05/17
Uptime: -48 years, 224 days, 10 hours, 28 minutes and 57 seconds
Shutdown: BAD at 03:00:34 01/01/70
Downtime: 47 years, 140 days, 14 hours, 54 minutes and 41 seconds

Startup: 20 at 17:55:15 09/05/17
Uptime: -48 years, 224 days, 9 hours, 6 minutes and 5 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 140 days, 18 hours, 53 minutes and 34 seconds

Startup: 21 at 21:54:54 09/05/17
Uptime: -48 years, 224 days, 5 hours, 6 minutes and 25 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 19 hours, 0 minutes and 35 seconds

Startup: 22 at 22:01:54 09/05/17
Uptime: -48 years, 224 days, 4 hours, 59 minutes and 26 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 140 days, 19 hours, 16 minutes and 24 seconds

Startup: 23 at 22:17:44 09/05/17
Uptime: -48 years, 224 days, 4 hours, 43 minutes and 36 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 140 days, 19 hours, 32 minutes and 28 seconds

Startup: 24 at 22:33:48 09/05/17
Uptime: -48 years, 224 days, 4 hours, 27 minutes and 31 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 20 hours, 11 minutes and 9 seconds

Startup: 25 at 23:12:28 09/05/17
Uptime: -48 years, 224 days, 3 hours, 48 minutes and 51 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 20 hours, 33 minutes and 53 seconds

Startup: 26 at 23:35:12 09/05/17
Uptime: -48 years, 224 days, 3 hours, 26 minutes and 7 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 20 hours, 42 minutes and 39 seconds

Startup: 27 at 23:43:58 09/05/17
Uptime: -48 years, 224 days, 3 hours, 17 minutes and 21 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 20 hours, 57 minutes and 50 seconds

Startup: 28 at 23:59:09 09/05/17
Uptime: -48 years, 224 days, 3 hours, 2 minutes and 10 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 21 hours, 9 minutes and 50 seconds

Startup: 29 at 00:11:09 10/05/17
Uptime: -48 years, 224 days, 2 hours, 50 minutes and 10 seconds
Shutdown: BAD at 03:01:19 01/01/70
Downtime: 47 years, 140 days, 21 hours, 21 minutes and 59 seconds

Startup: 30 at 00:23:18 10/05/17
Uptime: -48 years, 224 days, 2 hours, 38 minutes and 3 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 141 days, 5 hours, 49 minutes and 43 seconds

Startup: 31 at 08:51:04 10/05/17
Uptime: -48 years, 223 days, 18 hours, 10 minutes and 17 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 141 days, 6 hours, 1 minute and 9 seconds

Startup: 32 at 09:02:30 10/05/17
Uptime: -48 years, 223 days, 17 hours, 58 minutes and 50 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 141 days, 6 hours, 30 minutes and 21 seconds

Startup: 33 at 09:31:41 10/05/17
Uptime: -48 years, 223 days, 17 hours, 29 minutes and 39 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 141 days, 6 hours, 39 minutes and 37 seconds

Startup: 34 at 09:40:57 10/05/17
Uptime: -48 years, 223 days, 17 hours, 20 minutes and 26 seconds
Shutdown: BAD at 03:01:23 01/01/70
Downtime: 47 years, 141 days, 6 hours, 46 minutes and 40 seconds

Startup: 35 at 09:48:03 10/05/17
Uptime: -48 years, 223 days, 17 hours, 12 minutes and 31 seconds
Shutdown: BAD at 03:00:34 01/01/70
Downtime: 47 years, 141 days, 7 hours, 12 minutes and 9 seconds

Startup: 36 at 10:12:43 10/05/17
Uptime: -48 years, 223 days, 16 hours, 48 minutes and 39 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 141 days, 9 hours, 9 minutes and 59 seconds

Startup: 37 at 12:11:21 10/05/17
Uptime: -48 years, 223 days, 14 hours, 50 minutes and 0 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 141 days, 12 hours, 53 minutes and 8 seconds

Startup: 38 at 15:54:29 10/05/17
Uptime: -48 years, 223 days, 11 hours, 6 minutes and 53 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 141 days, 15 hours, 0 minutes and 49 seconds

Startup: 39 at 18:02:11 10/05/17
Uptime: -48 years, 223 days, 8 hours, 59 minutes and 10 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 141 days, 15 hours, 39 minutes and 41 seconds

Startup: 40 at 18:41:02 10/05/17
Uptime: -48 years, 223 days, 8 hours, 20 minutes and 18 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 146 days, 0 hours, 15 minutes and 8 seconds

Startup: 41 at 03:16:28 15/05/17
Uptime: -48 years, 218 days, 23 hours, 44 minutes and 53 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 146 days, 17 hours, 17 minutes and 21 seconds

Startup: 42 at 20:18:42 15/05/17
Uptime: -48 years, 218 days, 6 hours, 42 minutes and 38 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 146 days, 18 hours, 24 minutes and 22 seconds

Startup: 43 at 21:25:42 15/05/17
Uptime: -48 years, 218 days, 5 hours, 35 minutes and 55 seconds
Shutdown: BAD at 03:01:37 01/01/70
Downtime: 47 years, 146 days, 18 hours, 40 minutes and 49 seconds

Startup: 44 at 21:42:26 15/05/17
Uptime: -48 years, 218 days, 5 hours, 18 minutes and 54 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 147 days, 15 hours, 22 minutes and 0 seconds

Startup: 45 at 18:23:20 16/05/17
Uptime: -48 years, 217 days, 8 hours, 38 minutes and 1 second
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 147 days, 15 hours, 28 minutes and 38 seconds

Startup: 46 at 18:29:59 16/05/17
Uptime: -48 years, 217 days, 8 hours, 31 minutes and 23 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 147 days, 16 hours, 8 minutes and 3 seconds

Startup: 47 at 19:09:25 16/05/17
Uptime: -48 years, 217 days, 7 hours, 51 minutes and 58 seconds
Shutdown: BAD at 03:01:23 01/01/70
Downtime: 47 years, 147 days, 17 hours, 11 minutes and 33 seconds

Startup: 48 at 20:12:56 16/05/17
Uptime: -48 years, 217 days, 6 hours, 48 minutes and 26 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 147 days, 17 hours, 43 minutes and 26 seconds

Startup: 49 at 20:44:48 16/05/17
Uptime: -48 years, 217 days, 6 hours, 16 minutes and 35 seconds
Shutdown: BAD at 03:01:23 01/01/70
Downtime: 47 years, 147 days, 18 hours, 27 minutes and 39 seconds

Startup: 50 at 21:29:02 16/05/17
Uptime: -48 years, 217 days, 5 hours, 32 minutes and 20 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 147 days, 18 hours, 44 minutes and 12 seconds

Startup: 51 at 21:45:34 16/05/17
Uptime: -48 years, 217 days, 5 hours, 15 minutes and 48 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 147 days, 19 hours, 6 minutes and 46 seconds

Startup: 52 at 22:08:08 16/05/17
Uptime: -48 years, 217 days, 4 hours, 52 minutes and 28 seconds
Shutdown: BAD at 03:00:36 01/01/70
Downtime: 47 years, 147 days, 20 hours, 34 minutes and 14 seconds

Startup: 53 at 23:34:50 16/05/17
Uptime: -48 years, 217 days, 3 hours, 26 minutes and 2 seconds
Shutdown: BAD at 03:00:52 01/01/70
Downtime: 47 years, 147 days, 20 hours, 39 minutes and 5 seconds

Startup: 54 at 23:39:57 16/05/17
Uptime: -48 years, 217 days, 3 hours, 21 minutes and 24 seconds
Shutdown: BAD at 03:01:21 01/01/70
Downtime: 47 years, 148 days, 20 hours, 41 minutes and 22 seconds

Startup: 55 at 23:42:43 17/05/17
Uptime: -48 years, 216 days, 3 hours, 18 minutes and 39 seconds
Shutdown: BAD at 03:01:22 01/01/70
Downtime: 47 years, 148 days, 20 hours, 53 minutes and 2 seconds

Startup: 56 at 23:54:24 17/05/17
Uptime: -48 years, 216 days, 3 hours, 6 minutes and 56 seconds
Shutdown: BAD at 03:01:20 01/01/70
Downtime: 47 years, 148 days, 21 hours, 15 minutes and 59 seconds

Startup: 57 at 00:17:19 18/05/17
Uptime: -48 years, 216 days, 2 hours, 43 minutes and 53 seconds
Shutdown: BAD at 03:01:12 01/01/70
Downtime: 47 years, 148 days, 21 hours, 37 minutes and 10 seconds

Startup: 58 at 00:38:22 18/05/17
Uptime: 12 minutes and 56 seconds

root@raspbx:~/tuptime# tuptime -V
tuptime version 3.3.1

hmank ~ > tuptime
ERROR:root:Detected a new system startup but the values are not saved into db.
ERROR:root:Tuptime execution user can't write into db file: /var/lib/tuptime/tuptime.db
hmank ~ > systemctl list-timers
NEXT                         LEFT                LAST                         PASSED             UNIT                         ACTIVATES
Fri 2019-03-22 13:10:00 CST  22s left            Fri 2019-03-22 13:08:15 CST  1min 22s ago       tuptime.timer                tuptime.service

After shutdown by KDE, boot get above error.

OS: Manjaro KDE.

hi!

this is pretty cool software! i see there is a debian package in the deb-package directory - where does it come from? How is it generated?

Normally, you commit only the debian/ directory into source control, and the .deb is distributed seperately. You could, for example, ship them with your regular github releases. Obviously, the .deb should also be shipped with Debian itself, which would widen the distribution of this software significantly! There is a RFP (Request For Package) in the Debian BTS (Bug Tracking System) here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638422

I would even go as far as recommending you start with a new repository, to remove all those binary files from the history. Right now, about 80% of the size of the repository is the .git history, which is huge - normally, it should closer to 50% for small shell scripts like this...

Hi, I've installed tuptime on a lot of Red Hat 6.x servers, but since I also install redhat-lsb-core, which brings the file /lib/lsb/init-functions, the installer fails in recognizing the system and tries to use the Debian code to setup the init files ( update-rc.d tuptime defaults ) which is obviously not available.
I just swapped the two checks in tuptime-install.sh so that Debian comes last and Red Hat is tested before and the install is correct. Or maybe you can check for some other Debian specific file to make the correct choice.
Anyway thanks for this good program.

Hi, tuptime on AUR has been marked out of date and no longer works.

Installing via one-line shell script doesn't work for me either.

I have Garuda Linux, all updated with zen kernel 5.15.

every 5 minutes the cronjob from tuptime is spamming in /var/log/auth.log

Jan 10 00:35:01 MY-PC CRON[2701]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 10 00:35:01 MY-PC CRON[2701]: pam_unix(cron:session): session closed for user root

i am using Xubuntu 18.04 with tuptime version (3.3.3)

do you still plan on taking on the official debian packaging? or should i package 3.2.3 for you in debian now?

After install tuptime with pkg in FreeBSD 11.1 and enable it in /etc/rc.conf, the service not start.

Steps to reproduce and debug rc.conf:

# pkg install tuptime

# echo 'tuptime_enable="YES"' >> /etc/rc.conf

# echo 'rc_debug="YES"' >> /etc/rc.conf
# echo 'rc_info="YES"' >> /etc/rc.conf

# reboot

# dmesg -a | less 

...skipping...
/etc/rc: DEBUG: checkyesno: tuptime_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: tuptime_start
Shared object "libpython2.7.so.1" not found, required by "python2.7"
/etc/rc: DEBUG: run_rc_command: doit: ldconfig_start
/etc/rc: DEBUG: checkyesno: ldconfig_insecure is set to NO.
/etc/rc: DEBUG: checkyesno: rc_startmsgs is set to YES.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib

It would be nice if the README.md would state the differences (advantages/disadvantages compared) to uptimed and downtimed.

hi

i have tried building the package here:

[1029]anarcat@curie:tuptime$ DIST=sid ARCH=amd64 gbp buildpackage
dh clean --with=systemd
   dh_testdir
   dh_auto_clean
   dh_clean
gbp:info: Creating tuptime_3.3.0.orig.tar.gz from '3.3.0'
gbp:info: Exporting 'HEAD' to '/home/anarcat/src/build-area/tuptime-tmp'
gbp:info: Moving '/home/anarcat/src/build-area/tuptime-tmp' to '/home/anarcat/src/build-area/tuptime-3.3.0'
Building with cowbuilder for distribution sid, architecture amd64
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: dh-systemd (>= 1.5)
W: Unmet build-dependency in source
dpkg-buildpackage: info: source package tuptime
dpkg-buildpackage: info: source version 3.3.0-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Ricardo Fraile <[email protected]>
 dpkg-source --before-build tuptime-3.3.0
 fakeroot debian/rules clean
dh clean --with=systemd
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b tuptime-3.3.0
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building tuptime using existing ./tuptime_3.3.0.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
 tuptime-3.3.0/README.md
 tuptime-3.3.0/tuptime-manual.txt
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/tuptime_3.3.0-3.diff.MSwWeC
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b tuptime-3.3.0 gave error exit status 2
gbp:error: '/usr/bin/git-pbuilder' failed: it exited with 2
[1030]anarcat@curie:tuptime1$ 

The important bit is:

[...]
dpkg-source: info: local changes detected, the modified files are:
 tuptime-3.3.0/README.md
 tuptime-3.3.0/tuptime-manual.txt
dpkg-source: error: aborting due to unexpected upstream changes [...]

This is because of the changes to the readme and manual made in #30 and #29. Since those are changes that affect files outside of the debian/ directory, dpkg-source finds (correctly) that there are non-debian changes to the package that are not reflected the tarball.

i think the simplest fix may be for you toswitch back to making this a "native" package. i think this would be simply changing the version number to (say) 3.3.1 and changing the debian/source/format to 3.0 (native).

this does mean that you will need to tag a new release here any time you want to upload a new package into Debian, but that's you are doing anyways.

as things stand, i can't upload the package like this because of those changes.

After update a system with tuptime 2.6 to 3.0, tuptime execution report the following error:

File "/usr/bin/tuptime", line 482, in
main()
File "/usr/bin/tuptime", line 356, in main
conn.execute('select count(endst) from tuptime where endst = 0 and oid < (select max(oid) from tuptime)')
sqlite3.OperationalError: no such column: endst

Hi All,

Good day!

We have requirement to provide server availability hence using tuptime command to achieve.But there is an issue to exclude certain date downtime as we perform maintenance activity.

Example Output:

System startups: 4 since 04:06:57 PM 03/12/2022
System shutdowns: 0 ok + 3 bad
System life: 46d 23h 56m 38s

System uptime: 99.99% = 46d 23h 47m 19s
System downtime: 0.01% = 9m 19s

Average uptime: 11d 17h 56m 50s
Average downtime: 3m 6s

Current uptime: 3d 1h 47m 24s since 02:16:11 PM 04/25/2022

tuptime -t

From below output we would like to exclude march 12th downtime and calculate the System uptime:

No. Startup T. Uptime Shutdown T. End Downtime

1 04:06:57 PM 03/12/2022 43d 21h 48m 47s 01:55:44 PM 04/25/2022 BAD 1m 5s
2 01:56:49 PM 04/25/2022 5m 20s 02:02:09 PM 04/25/2022 BAD 3m 30s
3 02:05:39 PM 04/25/2022 5m 48s 02:11:27 PM 04/25/2022 BAD 4m 44s
4 02:16:11 PM 04/25/2022 3d 1h 47m 31s

Regards
Kumar

A minor issue I found with the RPM spec file in recent Fedora systems, it requires the addition of:

BuildRequires: systemd

to include the definition of %{_unitdir}

(Ref: https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations )

it looks like tuptime runs as root all the time... is that really necessary?

couldn't it be running as a dedicated user?

tuptime version 3.3.1. On raspberry pi - Raspbian GNU/Linux 9 (stretch) tuptime gives:
System downtime: -0.0 % - -1 years, 364 days, 23 hours, 59 minutes and 52 seconds

Full tuptime output:
System startups: 6 since 11:40:24 10/03/19
System shutdowns: 5 ok - 0 bad
System uptime: 100.0 % - 13 days, 3 hours, 12 minutes and 5 seconds
System downtime: -0.0 % - -1 years, 364 days, 23 hours, 59 minutes and 52 seconds
System life: 13 days, 3 hours, 11 minutes and 58 seconds

Largest uptime: 5 days, 0 hours, 0 minutes and 0 seconds from 22:15:01 11/03/19
Shortest uptime: 1 hour, 7 minutes and 56 seconds from 11:40:24 10/03/19
Average uptime: 2 days, 4 hours, 32 minutes and 1 second

Largest downtime: -1 years, 364 days, 23 hours, 59 minutes and 58 seconds from 12:48:20 10/03/19
Shortest downtime: -1 years, 364 days, 23 hours, 59 minutes and 58 seconds from 12:48:20 10/03/19
Average downtime: -1 years, 364 days, 23 hours, 59 minutes and 58 seconds

Current uptime: 16 hours, 37 minutes and 22 seconds since 22:15:00 22/03/19

In tuptime Python code, sys.exit(-1) is used for error code. Generally, we use 1 for error code in this case => sys.exit(1).

What do you think of https://github.com/alexmyczko/ruptime ?

Hi, for distributions that use systemd, it would probably make sense to use tmpfiles.d to create and manage permissions for the /var/lib/tuptime/ directory.

This makes little difference to the user, but in combination with the already existing sysusers.d config would simplify packaging.

Hi,
i need the reboot count of the server in the past 24 hrs, found that tuptime --tsince -86400 returns the system info for the past 24 hrs, can anyone help to get the reboot count.
Thanks In Advance

the changelog from the debian package is also missing form the source tree. just in case it got lost, here is a copy:

tuptime (3.2.01) stable; urgency=low

  * Detect database modification

 -- Ricardo F. <[email protected]>  Mon, 12 Oct 2015 11:00:00 -0400

tuptime (3.2.00) stable; urgency=low

  * Print singular names if is the case
  * Fix round and decimals values
  * Clean and order code

 -- Ricardo F. <[email protected]>  Mon, 05 Oct 2015 11:00:00 -0400

tuptime (3.1.00) stable; urgency=low

  * Register used kernels
  * Adding kernel option

 -- Ricardo F. <[email protected]>  Mon, 28 Sep 2015 11:00:00 -0400

tuptime (3.0.00) stable; urgency=low

  * Change printed output format
  * Adding max/min uptime/downtime reports
  * Adding table format output
  * Rename enumerate option to list and change output format
  * Adding sorting options
  * Change database schema
  * Clean and order code

 -- Ricardo F. <[email protected]>  Fri, 25 Sep 2015 11:00:00 -0400

tuptime (2.6.10) stable; urgency=low

  * Compatibility between python2.7 and python3.X
  * Removing unused modules

 -- Ricardo F. <[email protected]>  Thu, 10 Aug 2015 11:00:00 -0400

tuptime (2.5.20) stable; urgency=low

  * Setting data type for ok/bad shutdown in db creation

 -- Ricardo F. <[email protected]>  Sat, 08 Aug 2015 11:00:00 -0400

tuptime (2.5.12) stable; urgency=low

  * Setting max decimals in the output
  * Fix data type for the ok/bad shutdown registry in db wich cause incorrect
    counter output

 -- Ricardo F. <[email protected]>  Fri, 07 Aug 2015 11:00:00 -0400

tuptime (2.5.00) stable; urgency=low

  * Fix false shutdown count and correct locale date format

 -- Ricardo F. <[email protected]>  Tue, 04 Aug 2015 11:00:00 -0400

tuptime (2.4.26) stable; urgency=low

  * Fix from other point of view false shutdown bug

 -- Ricardo F. <[email protected]>  Tue, 04 Aug 2015 10:00:00 -0400

tuptime (2.4.10) stable; urgency=low

  * Fix false wrong shutdown bug when some kernels rarely report +1 or -1
    second inside /proc/stat btime variable

 -- Ricardo F. <[email protected]>  Wed, 26 Jul 2015 10:00:00 -0400

tuptime (2.4.00) stable; urgency=low

  * Adding downtimes reports
  * Adding enumerate option
  * Fix bad shutdowns count

 -- Ricardo F. <[email protected]>  Wed, 20 Jul 2015 10:00:00 -0400

tuptime (2.2.00) stable; urgency=low

  * Completely rewritten in python

 -- Ricardo F. <[email protected]>  Wed, 06 May 2015 10:00:00 -0400

tuptime (1.6.2) stable; urgency=low

  * New init script for debian 7 wheezy

 -- Ricardo F. <[email protected]>  Thu, 14 May 2013 10:00:00 -0400

tuptime (1.6.0) stable; urgency=low

  * Remove usage of syslog for more quick output.
  * Change output.
  * Print rate in output.

 -- Ricardo F. <[email protected]>  Thu, 17 Jan 2012 10:00:00 -0400

tuptime (1.5.0) stable; urgency=low

  * Print estimated uptime between starts.
  * Print actual uptime for the system.
  * Fix and improve code, remove repetitive lines and minnor bugs.
  * Check if the variable in the conf file is a number.
  * Start using Scalar::Util module.
  * Print system uptime date.
  * Fix bug in first update

 -- Ricardo F. <[email protected]>  Thu, 10 Oct 2011 10:00:00 -0400

tuptime (1.4.0) stable; urgency=low

  * Print time more accurate.
  * Cron line change to 5 minutes.
  * Print time values in live time without update.

 -- Ricardo F. <[email protected]>  Sat, 06 Aug 2011 10:00:00 -0400

tuptime (1.3.0) stable; urgency=low

  * Jump blank lines in conf file.
  * Adding #REPLACEAT feature.

 -- Ricardo F. <[email protected]>  Mon, 20 Jun 2011 10:00:00 -0400

tuptime (1.2.0) stable; urgency=low

  * Change speak option to verbose.
  * Fix lost information in files when update.
  * Minnor corrections in text strings.

 -- Ricardo F. <[email protected]>  Mon, 13 Jun 2011 10:00:00 -0400

tuptime (1.1.0) stable; urgency=low

  * Any user can print the times, not only root.
  * Minnor changes to speak option.
  * Minnor corrections.

 -- Ricardo F. <[email protected]>  Fri, 10 Jun 2011 10:00:00 -0400

tuptime (1.0.0) stable; urgency=low

  * First release.

 -- Ricardo F. <[email protected]>  Wed, 23 Mar 2011 10:02:18 -0400

this should be in a CHANGES file at the source of the git repository.

optionally, you can also maintain it in the debian/changelog directory if you are willing to (eventually?) maintain the package yourself.

i am almost done with the package, i will submit it into debian soon, and will submit a pull request here to integrate it directly here.

Python f-strings were introduced in 3.6 (if i recall correctly), which officially went EOL 12-23-2021. See here. Is there any interest in converting to f-strings? It would break compatibility before 3.6, but could simplify some of the printing functions and I may have some cycles to work on it.

so, another thing that is missing here is proper releases. i see zero releases in the release tab, it could be a product of rewriting the history...

i would also recommend using semantic versionning for naming the releases!

looking at the freebsd port makefile, i'll assume the latest code is 3.2.01, but since i am not sure the release is actually associatd with the last commit, i will add a git commit id to the debian version number.

I installed tuptime yesterday, and use shutdown-h 0 switch off my PC.

Now, tuptime show me a bad.