Measure system runtime with tuptime Stopwatch

Measure system runtime with tuptime Stopwatch

Article from Issue 241/2020

How long has the Linux server been running without rebooting? And how often has the system rebooted without you noticing? These questions and more are answered by the tuptime tool.

If a Linux system has been running for a long time, this is definitely proof of its stability, but – depending on the distribution – some updates might be waiting to install. Conversely, if the system reboots very frequently, there may be a configuration error – or maybe a hardware component is slowly deteriorating. On a workstation computer, such restarts are quickly noticed, but not necessarily on a remote server that is running quietly and well away from the action.

How long a system has been running continuously can be determined at the command line by a call to uptime. But you might also want to try tuptime [1], a similar tool whose name is based on a contraction of "total uptime." It outputs far more information, including valuable information in the form of the number of reboots and the kernel version used.


While uptime is available on almost every system, you need to install tuptime separately. Some distributions already have the tool in their repositories, such as Debian and Ubuntu. Arch Linux users will find tuptime in the AUR and CentOS users in the EPEL repository. On any Linux system, you can install the tool with the following:

$ curl -Ls | sudo bash

Tuptime itself consists of a Python script and requires Python 3 with the modules sys, os, optparse, sqlite3, locale, platform, datetime, and logging. These modules should be preinstalled on most distributions. For more information about installation, see the box "In the Background."

In the Background

The system calls tuptime briefly during the boot and shutdown processes. In each case, the tool notes the system time. It is from the timestamps collected in this way that tuptime ultimately calculates the total runtime and all other values.

To make tuptime start automatically at boot and shutdown time, sets up some startup scripts. For example, it sets up a corresponding service unit on a system with systemd. Besides systemd, the installation script also supports SysVinit and OpenRC. When using the installation script, tuptime also always runs under its own user account, named _tuptime.

If at some point the power should suddenly fail, tuptime would not notice anything. As a consequence, the timestamp for the shutdown would be missing, and this would prevent the tool from calculating the correct total runtime. For this reason, the installation script additionally sets up a cron job, which in turn ensures that tuptime is launched at regular intervals. All timestamps noted by tuptime end up in a small SQLite database, which is located below /var/lib/tuptime/tuptime.db by default.

Time Measurement

After setting up the program, query the current status via tuptime in the terminal. The tool already provides some basic information (Figure 1): At the very top; it shows the number of system starts. Next to it you can see the time and date since the software started counting the starts. Tuptime doesn't capture events before this date. To get a complete picture, set up the program as soon as possible after system installation.

Figure 1: Shortly after the install, tuptime cannot give you very much information, but over time, the data starts to give you a better impression of the computer's behavior.

Next, tuptime tells you how often the system has been shut down (System shutdowns). Pay special attention to the number of uncontrolled shutdowns labeled bad. If this figure increases rapidly, there is a major problem, for example an unstable power supply. System life indicates how long tuptime has been monitoring the system. If you installed tuptime directly after the installation of the distribution, this value corresponds to the time since the first boot.

This is followed by the total system uptime (System uptime) and the total time the computer was powered off (System downtime). If the percentage of downtime exceeds 50 percent, the computer was off longer than in operation. How long the system was in operation on average is indicated by the value following Average uptime. Similarly, Average downtime indicates how long the computer was switched off on average. The final value is the time since the last system start (Current uptime).

Display Options

The tuptime -l command returns a list with all startup operations. In the list, you can see in detail when the system was in operation and for how long. If the list seems too confusing, tuptime -t converts the data to tabular form like shown in Figure 2. The additional -r parameter reverses the order; the last system start appears at the top.

Figure 2: Tuptime offers different display formats. There has been a reboot since the tool was installed, so two system starts have been counted.

If you still feel overwhelmed by the volume of information, the display can be limited to a certain period of time. For example, if you want to know when and for how long the system was active between July 27 and July 28, 2020, just call tuptime with the command:

$ tuptime --tsince=$(date --date="2020-07-27" +%s) --tuntil=$(date --date="2020-07-28" +%s)

The --tsince and --tuntil parameters each expect a timestamp that is calculated by date. Tuptime also outputs these timestamps with the -s parameter.

Alternatively, you can limit the output to very specific startup operations. For example, if you are interested in how long the system ran from the very first to the fifth logged startup, use the following:

$ tuptime --since 1 --until 5

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Introduction

    This month in Linux Voice.

  • Charly's Column

    Who has the longest uptime? Linux systems used to win hands down when it comes to maximum uptime without rebooting. Today, uptime statistics help admins with monitoring tasks and discovering tricky bugs.

  • Fabric Python Library

    The Fabric Python library makes it extremely easy to create repeatable scripts of commands over SSH to any number of servers.

  • KSplice

    Uptime is often just as important as updates. But doesn't a kernel patch require a reboot? Ksplice lets you have your cake and eat it too.

  • Script Dialogs

    Starting a script on a Linux server with just a few mouse clicks sounds more complicated than it really is. If you want to create attractive and interactive dialogs for your desktop users, all you need is a small utility called SSH and a little Bash know-how.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95