Read Uptime and Idle Time from /proc/uptime

Divide the two numbers in /proc/uptime to get a CPU percentage and you get a plausible-looking figure that is wrong. Allow about ten minutes to read both fields properly. You need a Linux shell and permission to read /proc; no package installation or elevated privileges are required.

The examples describe the installed local source, proc_uptime(5) from Linux man-pages 6.7, dated 15 August 2023. The file is a live kernel interface, so its numbers will change between commands and will differ on every machine.

1. Read the raw values

Start with a read-only command. It changes no system state:

$ cat /proc/uptime
123456.78 987654.32

The file contains exactly two numbers in seconds. The first is system uptime, including time spent suspended. The second is time spent in the idle process. The values are normally decimal numbers, so keep the fractional part if you need sub-second reporting.

Checkpoint: confirm that the file is present and has two whitespace-separated fields:

$ awk 'NF == 2 && $1 ~ /^[0-9]+(\.[0-9]+)?$/ && $2 ~ /^[0-9]+(\.[0-9]+)?$/ { print "two numeric fields"; ok=1 } END { exit ok ? 0 : 1 }' /proc/uptime
two numeric fields

If this check fails, inspect the exact file with od or cat -A before building a parser around assumptions. Do not replace /proc/uptime: it is supplied by the kernel, not a normal editable file.

2. Convert uptime into days, hours and minutes

For a human-facing status line, use the first field and let awk perform the arithmetic:

$ awk '{
    total = int($1)
    days = int(total / 86400)
    hours = int((total % 86400) / 3600)
    minutes = int((total % 3600) / 60)
    seconds = total % 60
    printf "uptime: %dd %02dh %02dm %02ds\n", days, hours, minutes, seconds
}' /proc/uptime
uptime: 1d 10h 17m 36s

The displayed result is an example. Your output should agree with the first value from the preceding read, apart from the time taken between commands. The conversion deliberately truncates fractional seconds because a compact operational status line rarely needs them.

For a script that needs the original precision, capture the first field directly rather than parsing a formatted sentence:

$ uptime_seconds=$(awk '{ print $1 }' /proc/uptime)
$ printf 'uptime seconds: %s\n' "$uptime_seconds"
uptime seconds: 123456.78

Keep the value quoted when expanding it. Although the kernel currently emits a simple decimal, quoting avoids accidental word splitting if the value is passed through more processing later.

3. Interpret the idle field on a multi-CPU host

The second number is not a percentage and is not the idle time of one selected CPU. It is the amount of time spent in the idle process, and the kernel documentation describes it as the combined idle time of all CPUs.

That is why the second field can be larger than the first. On a four-CPU machine, four CPUs being idle for one second contributes roughly four CPU-seconds.

Warning: do not calculate a CPU utilisation percentage by dividing the second field by the first field. That ratio has no stable meaning when the CPU count changes.

To see the relationship on your own host, print both fields and the number of configured processors:

$ awk '{ printf "uptime=%s seconds idle=%s seconds CPUs=%d\n", $1, $2, n }' n="$(getconf _NPROCESSORS_ONLN)" /proc/uptime
uptime=123456.78 seconds idle=987654.32 seconds CPUs=8

The getconf value is context for interpretation, not part of the /proc/uptime format. If it is unavailable in a minimal environment, omit it and use nproc or another host-specific source. A container can also have a CPU view that differs from the host, so do not treat this one-line comparison as a complete capacity or load report.

4. Use a stable snapshot in monitoring code

Read both fields from one open of the file. This avoids mixing values obtained at different moments:

$ read -r uptime_seconds idle_seconds < /proc/uptime
$ printf 'uptime=%s idle=%s\n' "$uptime_seconds" "$idle_seconds"
uptime=123456.78 idle=987654.32

For a monitoring agent, read the file at a fixed interval and calculate differences between successive samples. The first field's difference approximates elapsed wall-clock uptime. The second field's difference is aggregate idle CPU time across the interval, and it can exceed the elapsed time on a multi-CPU system, which is expected.

A reboot resets the counters, and suspend time is included in uptime according to the local manual page. If a sample decreases unexpectedly, treat it as a counter reset or a read/parsing problem, not as negative running time. Reset your baseline and record the event.

Common traps

Recovery: there is nothing to undo because every example only reads the interface or computes values in the shell. If a monitoring script has stored a bad baseline, stop that script or remove only its own generated state after checking the path. Never delete files under /proc as a recovery step.

Done means