Inspect Linux Pending Timers with /proc/timer_list

You will learn how to take a read-only snapshot of Linux's pending high-resolution timers, clock-event sources and their parameters. The method uses the virtual file /proc/timer_list, so it does not stop timers, alter scheduling or change a service. Allow about 10 minutes. You need a shell, and on many systems you will need sudo to read the file.

What this file is for

/proc/timer_list is a kernel-provided diagnostic file. The local proc_timer_list(5) page describes it as a human-readable list of all currently pending high-resolution timers, all clock-event sources, and their parameters. It has existed since Linux 2.6.21. The installed manpage is from the Debian manpages package version 6.7-2, dated 15 August 2023. The package version describes the documentation, not the running kernel.

This distinction matters. The file is a report of the current kernel state, not a configuration file and not a timer-management interface. It has no command-line options, and writing to it is not a supported way to cancel or create a timer. Use it when investigating timer behaviour, clock sources or a timing-related problem. Do not treat its layout as a stable machine-readable API.

Step 1: check the path before reading it

Start with an ordinary, non-privileged check. This confirms that the procfs entry exists and shows its permissions without changing anything.

test -e /proc/timer_list && stat -c 'path=%n mode=%A owner=%U group=%G' /proc/timer_list

On a kernel exposing the entry, the command prints a line beginning with path=/proc/timer_list. The mode and owner are host-specific. A missing path means that this kernel or procfs setup is not exposing the entry. Do not create a regular file with that name: it would hide the real diagnostic question and would not provide timer data.

Step 2: read a small part of the report

Use head first rather than dumping an unknown amount of kernel output into a terminal or log. This is a read-only operation and normally needs no elevated privilege if your account has access.

head -n 40 /proc/timer_list

Expect human-readable diagnostic text. The exact headings, values and ordering depend on the running kernel and the timers active at the instant of the read. Do not copy a sample from another machine into an incident report as if it described yours. The useful result is the output produced by this command on the affected host.

If the command prints Permission denied, retry the same read through the system's approved privilege path:

sudo head -n 40 /proc/timer_list

This is the first command in the guide that may require elevated privileges. sudo grants access to the process running head; it does not make the file writable and does not change any timer. If your account is not authorised for sudo, ask the system owner to run the read and provide the output needed for diagnosis. Do not loosen procfs permissions merely to avoid this check.

Step 3: save a snapshot for comparison

When the report needs to be compared with a later state, save it to a new file in a directory you own. Choose an explicit destination so that an existing file is not silently overwritten.

snapshot="/tmp/timer-list-$(date +%Y%m%d-%H%M%S).txt"
if sudo cat /proc/timer_list > "$snapshot"; then
    printf 'saved %s\n' "$snapshot"
else
    rm -f -- "$snapshot"
    printf 'could not read /proc/timer_list\n' >&2
    exit 1
fi

The command creates a point-in-time text snapshot under /tmp. The rm line is recovery for a failed read, so a partial file is not mistaken for a complete report. It does not touch the kernel interface. Because the report can contain host-specific scheduling details, handle the snapshot as operational data and remove it when it is no longer needed:

rm -f -- "$snapshot"

That removal is irreversible for this copy. It still leaves the kernel timers unchanged. If you need to keep evidence, move the file to the approved incident location instead of deleting it.

Step 4: compare without assuming a fixed format

A second snapshot can show that the report changes as timers are created and expire, but a textual diff is only a clue. Values may differ because time advanced, a process scheduled work, or the kernel selected a different clock-event state. Record the kernel release and the time of each read alongside the files.

uname -r
date --iso-8601=seconds
wc -l -- "$snapshot"
grep -n -E '(^|[[:space:]])(tick|clock|timer)' "$snapshot" | head -n 20

The last command is deliberately only a quick search. It may find nothing because field names and capitalisation are kernel-specific, so an empty result is not proof that no timers exist. For a complete investigation, read the whole snapshot and consult the kernel version's documentation or source rather than writing a parser against one example.

Common traps and boundaries

• Confusing observation with control: reading the file reports state. It does not cancel a timer, wake a task or configure a clock source.
• Expecting a portable schema: the manpage promises human-readable output, not stable field names. Keep parsers out of production decisions unless they are tied to a tested kernel range.
• Reading once and calling it a diagnosis: the list is a snapshot. Capture more than one sample when timing is central to the fault, and note the sampling times.
• Using broad privilege changes: do not change file modes, mount options or service settings just to read a diagnostic entry. Use the narrowest authorised read.
• Assuming absence means failure: a missing or inaccessible procfs entry can reflect the kernel, container policy or permissions. Check the environment before concluding that timers are broken.

Done means

• /proc/timer_list was checked without modifying the system.
• A permitted read produced a host-specific human-readable snapshot, or the permission/environment limitation was recorded.
• You know that the report covers pending high-resolution timers and clock-event sources at read time.
• Any temporary snapshot was either retained in an approved location or removed deliberately.