dmesg on Mac: No Flags Work, and Kernel Logs Last 23 Hours

I typed dmesg -w on the Mac mini that runs this business, expecting the Linux behaviour: watch kernel messages scroll by while something gets plugged in. It printed one line, usage: sudo dmesg, and exited 1. Plain dmesg without sudo did slightly better: Unable to obtain kernel buffer: Operation not permitted, then the same usage line, exit 1. So dmesg on Mac is real, but it has no flags at all, and the log where the kernel's messages actually end up had kept only the last 23 hours of them on a machine that had been up for six days.

Below is what each route returns on macOS 26.4.1 without root, what people on Ask Different actually reach for dmesg to do, and an 18-line shell function that gives back -w, -T and --level=err.

dmesg on Mac takes no arguments, by design

/sbin/dmesg here is a 101,168-byte binary whose embedded version string says PROJECT:system_cmds-1042.100.6.0.1. Apple publishes that exact tag, and the source for dmesg.c is 101 lines, most of them license header. The part that matters:

if (argc > 1)
	usage();          /* prints "usage: sudo dmesg", exit(1) */

sysctlbyname("kern.msgbuf", &msgbufsize, ...);
data_size = proc_kmsgbuf(msgbuf, msgbufsize);

Any argument at all, valid on Linux or not, goes straight to usage(). I tried -T, -w, -H, -l and --follow; all five printed the usage line and exited 1 without touching the buffer. Without arguments the program asks the kernel for its message buffer through proc_kmsgbuf(), which refuses a normal user, hence the "Operation not permitted".

The man page disagrees with the binary. man dmesg on the same machine still shows dmesg [-M core] [-N system], dated June 5, 1993, and the dmesg.8 in the same tag says the same. Pass -M and you get the usage line like everything else.

The buffer itself is small. sysctl kern.msgbuf reports 131072, so 128 KB. I couldn't read it: sudo -n true answers "a password is required" on this headless box, and nobody types passwords into it. So I can't tell you what sudo dmesg prints on macOS 26. The one recent example I found is an Ask Different question from a macOS 13.7.3 iMac, where a clean install produced AppleKeyStore errors at "> 40 lines per second" in lines shaped like [ 2281.103104]: ..., seconds since boot rather than wall-clock time. It has no answers.

Installing GNU's version doesn't help either. As I found when writing about lsblk on Mac, the util-linux formula lists dmesg among the tools it leaves out on macOS.

Where the kernel's messages actually go: the unified log

Since macOS 10.12 the kernel writes to the same unified log as everything else, and a normal user can read it with log show. The predicate is process == "kernel". One hour of it, 20:04 to 21:04 KST on October 4:

Sender inside the kernel	Lines in 1 hour	Share
AppleSystemPolicy	101,520	73.2%
(no sender name, mostly Wi-Fi driver)	21,846	15.7%
kernel	8,537	6.2%
AppleH16ANEInterface	4,471	3.2%
Sandbox	1,569	1.1%
everything else	822	0.6%
Total	138,765	15.1 MB of message text

That's about 38 lines a second. Almost three quarters come from one place. AppleSystemPolicy logged three messages, 32,400 times each, in a fixed rhythm: Security policy would not allow process for an Electron helper of an app installed on this Mac, Sleep interrupted, and Could not find reference N, process must have died. That's a background app retrying something nine times a second, and on your Mac it will be some other app. The point is that a single noisy sender can bury the kernel's own stream, so the first useful filter is to drop it.

For comparison, 15.1 MB an hour is about 115 times the 128 KB dmesg buffer. I don't know which subset of these lines reaches that buffer, because checking would need root.

The 23-hour window

This is the part that surprised me. The Mac had booted on September 28 at 10:09 KST. When I wrote about the log show command I measured about fifteen days of retention in the log store, and that still holds for other processes: an unfiltered query reached back to the === system boot marker on September 28. The kernel's lines didn't. The oldest kernel line on the machine was stamped 2026-10-03 21:57:33, about 23 hours before I looked. Counting kernel lines by date in that dump gave 277,853 for October 3, 2,930,313 for October 4, and zero for September 28 through October 2.

Two things follow. First, log show --last boot is not "since boot" for the kernel once the machine has been up a while. On this Mac it started at the same 21:57:33 line. If the reason you wanted dmesg was boot-time messages after a few days of uptime, they are gone, and no flag brings them back. Second, a window that starts before the retained range can misbehave. I asked for --start "2026-09-28 10:09:00" --end "2026-09-28 10:12:00". Instead of three minutes, it printed 3,394,108 kernel lines right up to the present; without the predicate the same query wrote 29.8 million lines, 3.7 GB, before it finished. The same flags with a window an hour back stopped exactly on time. The wall clock was wrong for the first stretch after this boot (early lines are stamped 01:09, followed by "system wallclock time adjusted"), which may be related, but I haven't proven why. Pipe exploratory queries through head until you trust the range.

What people use dmesg for on a Mac

I pulled every Ask Different question whose body mentions dmesg through the Stack Exchange API: 48 questions from 2011 to 2026, 121,968 views in total, 23 of them asked since 2020. Classifying by keywords in title and body, 36 of the 48 are about a USB device, disk or mount, 6 about boot or a kernel panic, and 6 about something else. The person in question 280716 put it plainly: "The Mac OS dmesg command is just useless", and asked for a way to "monitor in real time (like dmesg -w with Linux) the plugged devices". 2,747 views, no answers. Google's autocomplete tells the same story: after "dmesg examples", the most common completions for "dmesg mac" are "mac dmesg follow" and "macos dmesg follow".

For the device question specifically, the kernel log is only half the answer. The device trees live in the I/O Registry, which I covered in lsusb on Mac and lspci on Mac. The log tells you when something happened; the registry tells you what is attached now.

Linux dmesg flags and their macOS equivalents

Linux	macOS without sudo	Measured here
dmesg	log show --last 1h --predicate 'process == "kernel"'	138,765 lines/hour
dmesg -w	log stream --predicate 'process == "kernel"'	349 lines in 10 s; 91 without AppleSystemPolicy
dmesg -T	nothing to add; log prints wall-clock time
dmesg --level=err	add AND messageType == error	1,600/hour, 1,569 of them Sandbox denials
dmesg | grep -i usb	add AND eventMessage CONTAINS[c] "usb"	0 lines (nothing was plugged in)
journalctl -k	log show --kernel does not exist	"unrecognized option `--kernel'"

If you use zsh, type /usr/bin/log rather than log in scripts and functions. As the log show post explains, zsh has a builtin called log that takes no arguments and swallows the call.

A dmesg-style shell function

Here is the function. It defaults to the last hour with the AppleSystemPolicy flood removed, and accepts the four Linux habits that map cleanly:

kdmesg() {
  # Linux-style dmesg on macOS without sudo: reads the kernel's lines from the unified log
  local mode=show last=1h pred='process == "kernel" AND sender != "AppleSystemPolicy"'
  while [ $# -gt 0 ]; do
    case "$1" in
      -w|--follow) mode=stream ;;
      -T) ;;  # log already prints wall-clock time
      --level=err) pred="$pred AND messageType == error" ;;
      --since) last="$2"; shift ;;
      --all) pred='process == "kernel"' ;;
      *) echo "kdmesg: unsupported option $1" >&2; return 2 ;;
    esac
    shift
  done
  if [ "$mode" = stream ]; then
    /usr/bin/log stream --style compact --predicate "$pred"
  else
    /usr/bin/log show --style compact --last "$last" --predicate "$pred"
  fi
}

I tested it in zsh -f, Apple's bash 3.2.57 and /bin/sh. kdmesg --since 5m returned about 3,250 lines in each, kdmesg --level=err --since 5m 133 to 135, kdmesg -w 38 lines in five seconds, and an unknown flag returns 2 instead of silently doing something else. I named it kdmesg so it doesn't shadow /sbin/dmesg, which still works with sudo. Remember the 23-hour window above: --since 3d will run fine and simply start wherever the kernel's retained lines start.

FAQ

Why does dmesg say "Operation not permitted" on Mac?

macOS dmesg reads the kernel message buffer through proc_kmsgbuf(), which only root may call. Run it as sudo dmesg, or read the same kernel messages without root through the unified log with log show --predicate 'process == "kernel"' --last 1h.

Is there a dmesg -w on macOS?

No. The macOS dmesg rejects every argument with "usage: sudo dmesg" and exits 1. The equivalent is log stream --predicate 'process == "kernel"', which follows new kernel messages as they arrive and does not need sudo.

How do I see kernel messages from boot on a Mac?

Use log show --last boot --predicate 'process == "kernel"' soon after booting. The kernel's lines rotate out of the unified log faster than other processes' lines; on one Mac mini with six days of uptime, the oldest kernel line left was 23 hours old, so boot messages were no longer available.

Method: on 2026-10-04 between about 21:00 and 21:15 KST I ran every command above on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253, SIP enabled) as a normal user, six days after its last boot. The dmesg source and man page are from Apple's system_cmds-1042.100.6.0.1 tag, which matches the version string in the binary. Line counts come from log show --style ndjson parsed in Python; the 3.7 GB dump used for the per-day kernel counts was deleted afterwards. The 48 Ask Different questions were pulled through the Stack Exchange API the same evening and classified by keyword, so a few could sit in the wrong bucket. I did not run sudo dmesg, plug in a device, or test Intel Macs or macOS 15 and earlier, and retention on your Mac will depend on how chatty its kernel is.