An “Operation not permitted” response from `dmesg` is frustrating when you’re trying to read a kernel message. I find the distinction useful: the error concerns access to the buffer, not whether `dmesg` exists.
You can use `dmesg` without options to display the available kernel buffer. You’ll see the recorded boot and device activity.
What dmesg reads
The ring buffer is bounded. As new boot and device messages arrive, they can replace older entries, so dmesg is not a permanent archive.
With no options, dmesg displays the available buffer. Pipe it to less when you need to search or move through a long output without sending it all past the terminal.
sudo dmesg --color=never | less
less lets you move in either direction and search while the output stays on screen. The less command guide covers those keys.
The lines beginning with a number in square brackets carry a timestamp relative to boot. The text can identify a kernel version or describe device activity during startup.
| Output part | What it tells you |
|---|---|
| Bracketed number | Kernel timestamp relative to boot |
| Message text | Kernel or device event recorded in the buffer |
The Linux kernel overview explains where these messages come from.
Check access before filtering
A system can restrict access to the kernel buffer. When kernel.dmesg_restrict is set to 1, the kernel documentation says a reader needs the CAP_SYSLOG capability, so an unprivileged command can return “Operation not permitted.”
sysctl kernel.dmesg_restrict
- If the value is 1, unprivileged reads are blocked.
- Use sudo only when authorized. If access still fails, request an approved path instead of changing the kernel policy.
This unprivileged read makes the denial visible without color codes:
dmesg --color=never
The message describes a permission boundary, not a missing command or a malformed option. The Linux kernel’s dmesg_restrict documentation describes the capability required when the setting is enabled.
Search the buffer for a message
Pipe dmesg output to grep when you know a word the kernel may have used. The -i option ignores letter case, which helps when device names vary in capitalization.
sudo dmesg --color=never | grep -i "usb"
| Search term | Example use |
|---|---|
| usb | Find messages that mention USB devices or drivers |
| Linux version | Find the kernel version banner |
The command returns matching lines from the buffer, such as USB device detection or driver messages. No match does not prove that a device is absent, because the event may have aged out or the kernel may use different wording.
For a quick kernel-release lookup, search for the version banner:
sudo dmesg --color=never | grep "Linux version"
The banner describes the kernel that produced the boot message. Compare it with the currently running release using the Linux kernel version commands.
The keyboard example below shows matching log lines. Those records describe what the kernel logged at that time, not a current connection state.
If a matched line names a kernel module, the guide to loadable kernel modules explains how modules relate to drivers.
The grep command guide covers longer searches and regular expressions.
Follow new kernel messages
Use the follow option when you need to watch messages as the kernel adds them. It keeps the command open and requires a readable /dev/kmsg interface.
sudo dmesg --follow
- Start the command before repeating the action that should create a kernel message.
- Watch for a new line about the device or driver.
- Press Ctrl+C when you have the message you need.
If the command exits with a permission error, check the access section above. The util-linux manual documents –follow as a wait for new messages and limits it to systems where /dev/kmsg is readable.
Filter by facility or severity
Use the decode option to show a message’s facility and level as words. A facility is the message category, while a level is its priority.
sudo dmesg --decode
| Field | Example | What it identifies |
|---|---|---|
| Facility | kern | Kernel message category |
| Facility | daemon | Daemon message category |
| Level | warn | Warning priority |
| Level | err | Error priority |
Choose a facility
A comma-separated facility list selects message categories, not process names.
sudo dmesg --decode --facility=syslog,daemon
Choose a severity level
The level filter accepts comma-separated names. This example selects only warn and err priorities, excluding higher levels.
sudo dmesg --decode --level=warn,err
A severity label helps sort messages, but it does not diagnose the cause by itself. For a heat-related alert, compare the message with the steps in the Linux temperature guide.
Read dmesg timestamps carefully
The default number in square brackets is a kernel timestamp measured from boot, not a calendar time. Use a readable format when you need to line up a kernel event with another log.
sudo dmesg --time-format iso | tail -n 20
The ctime format is also available with the -T option. The util-linux manual warns that ctime and ISO timestamps can be inaccurate after suspend and resume, so do not treat them as precise event times in that case.
A dmesg timestamp marks when the kernel emitted a record, not how long the named process ran.
To query retained entries by time, use the date-range log filtering guide.
Save messages before clearing the buffer
The clear option empties the kernel ring buffer, which removes its diagnostic history from dmesg. Save any lines you may need before using it.
sudo dmesg --clear
| Option | Effect |
|---|---|
| –clear | Empty the buffer without printing it |
| –read-clear | Print the buffer, then empty it |
Neither option deletes entries already stored by systemd-journald. Journal retention depends on its storage configuration.
Use the journal when boot history matters
dmesg shows the kernel’s current ring buffer. If systemd-journald retained kernel entries, journalctl can query that separate journal, including records from an earlier boot.
sudo journalctl -k -b -n 5 --no-pager
The -k option selects kernel messages, and -b selects the current boot. Use -b -1 for the previous boot when those records were retained.
Journal storage can be volatile or persistent, depending on its configuration.
The journalctl manual documents boot selection. The storage manual explains whether entries persist.
If a kernel message points to overheating, check the device’s reported temperatures in the CPU and GPU temperature guide.
dmesg command questions
These answers cover the questions left after the command examples.
What does the dmesg command do in Linux?
dmesg displays or controls messages in the Linux kernel ring buffer. You can inspect boot and device events, then filter the output by text, facility, level, or time format.
Why does dmesg say Operation not permitted?
The kernel can restrict unprivileged access to its message buffer. If kernel.dmesg_restrict is 1, the kernel documentation requires CAP_SYSLOG for access. Use sudo only when your account is authorized.
How do I follow new dmesg messages?
Run dmesg with the –follow option. It waits for new kernel messages and requires readable /dev/kmsg. Press Ctrl+C to stop waiting.
Are dmesg timestamps accurate?
The default timestamp is relative to boot. Human-readable ctime and ISO formats can be inaccurate after system suspend and resume, as the util-linux manual warns.
Does dmesg –clear delete system logs?
No. It clears the kernel ring buffer read by dmesg, not entries already stored in the systemd journal. Journal retention depends on its storage configuration.