Read and Filter the Linux Kernel Log with dmesg

You will finish with a safe routine for inspecting the kernel ring buffer, narrowing noisy output, producing parseable records, and watching for new messages. The examples use the util-linux dmesg described by the local manpage as version 2.39.3. The executable found first on this machine reports util-linux 2.41.3, so check your own command rather than assuming every detail matches the manpage.

Allow about fifteen minutes. You need a shell and a readable kernel log. Reading the log is normally unprivileged, but many systems restrict it through the dmesg_restrict kernel setting. This guide does not change that setting, clear the buffer, or alter the console log level.

1. Confirm the command and permission boundary

Check which binary your shell will run and record its version. These are ordinary, read-only commands:

$ command -v dmesg
/usr/bin/dmesg
$ dmesg --version
dmesg from util-linux 2.39.3

Your path and version may differ. On this host, command -v dmesg resolves to a Linuxbrew binary reporting 2.41.3, while the installed manpage is from util-linux 2.39.3. That difference matters when a newer help screen offers an option absent from the local manual.

Now try a non-destructive read with the pager disabled:

$ dmesg --nopager
dmesg: read kernel buffer failed: Operation not permitted

If you see that error, the kernel is refusing this account's read. Do not treat sudo as a general repair. If you are authorised to inspect this host, ask an administrator to grant the necessary access or run the read through the approved administrative path. Do not disable dmesg_restrict just to make a one-off command work.

Checkpoint: continue only when a plain read returns messages, or when you have an approved privileged way to run the examples below.

2. Make a first readable capture

The default action displays the kernel ring buffer. For a terminal, human-readable output is easier to scan, and --nopager keeps the result in the terminal or a pipeline:

$ dmesg --human --nopager | sed -n '1,25p'
[    0.000000] Linux version ...
[    0.000000] ...

The lines and timestamps are host-specific. The command should either print records or report the permission failure described in step 1. Do not paste a large, unfiltered log into a ticket if it may contain device identifiers, filesystem paths or other machine-specific details.

For a stable, script-friendly form, request JSON instead:

$ dmesg --json --nopager | sed -n '1,3p'
{"sec.usec":"...","msg":"..."}

The exact fields depend on the records available. The local manual says JSON uses sec.usec timestamps and ignores options that control the ordinary display format. In particular, do not combine JSON with a styling expectation from human-readable output.

3. Filter by severity before you investigate

Kernel logs can contain routine information as well as failures. Restrict output to errors and warnings with a comma-separated level list:

$ dmesg --level=err,warn --nopager
[    1.234567] ... warning or error record ...

There may be no output, which is a valid result. The supported levels include emerg, alert, crit, err, warn, notice, info and debug. Add a plus sign to include more severe levels as well. For example, err+ includes error, critical, alert and emergency records.

$ dmesg --level=err+ --nopager
$ printf 'exit status: %s\n' "$?"
exit status: 0

A successful exit status means the query completed; it does not mean that the kernel is healthy. Interpret the records, and compare them with the time of the incident you are investigating.

4. Add timestamps without overtrusting them

Use ISO-like timestamps when you need to compare records between systems or feed them to another tool:

$ dmesg --time-format=iso --nopager | sed -n '1,5p'
2026-09-23T03:10:12,123456+01:00 ...

The local manual documents ctime, reltime, delta and iso. It also warns that human-readable timestamps can be inaccurate after suspend and resume because the source clock is not updated during that interval. Treat the timestamp as evidence to correlate, not as proof of the exact wall-clock event time.

To inspect a recent window, use relative or absolute limits:

$ dmesg --since '1 hour ago' --until now --nopager
... records from the requested interval ...

Quote time expressions containing spaces. If a time-window query returns nothing, widen the interval before concluding that no event occurred.

5. Follow new records during a test

When reproducing a hardware, driver or suspend problem, wait for new messages with --follow-new:

$ dmesg --follow-new --nopager
... waits here ...
[ 1234.567890] ... new record ...

Press Ctrl-C to stop the foreground reader. This does not clear the ring buffer. --follow is similar but can print existing messages before waiting. Follow mode requires a readable /dev/kmsg, so an older or restricted system may reject it even when another read mode works.

If a test is likely to produce sensitive output, redirect it to a file with an explicit, private destination and remove that file through your normal retention process afterwards. Do not use --noescape for routine viewing. dmesg escapes unprintable and terminal-control characters by default; disabling that protection can make log output alter the terminal or confuse downstream tooling.

6. Configure colours without changing log collection

Colour is a display setting, separate from the kernel buffer. The dmesg manpage says its colour support uses the util-linux terminal colour configuration facility. A user-specific directory overrides the global directory, so start with a per-user change when you only want to affect your account:

$ mkdir -p "$HOME/.config/terminal-colors.d"
$ touch "$HOME/.config/terminal-colors.d/dmesg.disable"
$ dmesg --color=auto --nopager | sed -n '1,5p'

The empty dmesg.disable file disables implicit dmesg colouring for your user. Remove that file to undo this example:

$ rm "$HOME/.config/terminal-colors.d/dmesg.disable"
$ test ! -e "$HOME/.config/terminal-colors.d/dmesg.disable" && echo 'dmesg colour override removed'
dmesg colour override removed

Removing a file is a state change, so check the path before running the command. Do not use sudo for this user-level example.

For a deliberate administrator-wide policy, the global equivalent is shown below. Creating or removing it needs elevated privileges and affects other users. The filename can also include a terminal identifier, such as [email protected]. More-specific matching names take priority over generic names. Scheme files use lines such as alert 37;41; keep that change separate from diagnosing the kernel event so a visual preference is not mistaken for a logging fix.

/etc/terminal-colors.d/dmesg.disable

7. Avoid commands that change state

Most useful investigations need no control operation. Treat these options as administrative actions:

• --clear removes the current ring-buffer contents.
• --read-clear prints the contents and then clears them.
• --console-level, --console-on and --console-off change whether messages are printed to the console.

Do not run them in a copy-and-paste diagnostic session. Clearing records destroys evidence for later investigation, and console-level changes can affect an operating system's visibility and noise. If one of these changes was explicitly authorised, record the previous setting and follow the host's rollback procedure before changing it.