dtrace System Integrity Protection Is On: Read Line Two

Every time I touch DTrace on this Mac mini, macOS greets me with the same sentence:

$ dtrace -l
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to initialize dtrace: DTrace requires additional privileges

Search that first line and the top answers tell you to reboot into Recovery and turn System Integrity Protection off. This machine runs headless, so a Recovery reboot means walking to it with a keyboard. Before doing that I wanted to know whether the first line was the thing stopping me. It was not. I ran all 45 DTrace-backed tools Apple ships on macOS 26.4.1, and that line is a warning which fires whether or not anything goes wrong.

The warning fires on a run that succeeds

The cheapest test: dtrace -e compiles the program and exits without asking the kernel to enable anything. I measured the exit status directly rather than through a pipe, because a pipe reports the exit code of the last command and would have hidden the answer.

$ dtrace -e -n 'BEGIN{exit(0);}'
dtrace: system integrity protection is on, some features will not be available
$ echo $?
0

Exit 0. The SIP line still printed. It is on stderr, it is not fatal, and on this machine it appears on a run that did exactly what I asked. Here is the full matrix of invocation forms I tried, all as a normal user, all with SIP enabled:

Invocation	Exit	SIP line?	Line after it
dtrace -V	0	no	none
dtrace (no arguments)	2	no	Usage: dtrace [-aACeFHlqSvVwZ] ...
dtrace -h	2	no	-h requires one or more scripts or enabling options
dtrace -e	0	yes	none
dtrace -e -n 'BEGIN{exit(0);}'	0	yes	none
dtrace -l	1	yes	DTrace requires additional privileges
dtrace -n 'syscall:::entry{exit(0);}'	1	yes	DTrace requires additional privileges
dtrace -c /bin/echo -n 'BEGIN{exit(0);}'	1	yes	DTrace requires additional privileges

The pattern is how far the process got. Runs that bail during argument parsing never print it; runs that reach library initialization always do. The warning states a fact about the machine, not about your command.

45 shipped tools, and what each one really said

macOS still ships the whole DTraceToolkit. I collected every executable text file under /usr/bin, /usr/sbin, /bin and /sbin whose contents mention dtrace: 45 files, all in /usr/bin, of which 25 carry a .d extension and 20 are wrappers without one.

Then I ran all 45 as a normal user with no arguments and recorded the first line that was not the SIP warning:

What happened	Count	Examples
Printed the SIP warning	38 of 45	opensnoop, execsnoop, iosnoop
Failed on DTrace requires additional privileges	35 of 45	opensnoop, bitesize.d, newproc.d
Never reached dtrace at all	7 of 45	dtruss, dappprof, dapptrace, lastwords, timerfires, timer_analyser.d, power_report.sh
Said plainly that root was needed	1 of 45	power_report.sh
Failed but exited 0	2 of 45	errinfo, imptrace

Three things in that table cost me time. First, 35 of the 45 tools fail for a reason that has nothing to do with SIP: I was not root. Exactly one, power_report.sh, says so in words a human wrote: Requires root privileges. Please re-run using sudo. The other 34 make you infer it from the word "privileges" sitting directly under a sentence about System Integrity Protection.

Second, errinfo and imptrace print both failure lines and then exit 0. I checked that twice without a pipe. If you call either from a script or a scheduled job, it passes.

Third, two tools failed on something else entirely. iotop and topsyscall died on TERM environment variable not set., which is my headless setup, not DTrace. And topsysproc has a shell bug on this build: /usr/bin/topsysproc: line 45: [: : integer expression expected. This is the same shape of problem as the airport command that macOS still ships but will not let you use: the binary is present, so you assume the tool is the problem.

What SIP actually restricts, according to Apple

The warning says "some features". I went looking for the list. man dtrace is 1,142 lines on this build and mentions System Integrity Protection in exactly two places:

• Destructive actions are refused even with -w while SIP is enabled.
• With default SIP settings, D programs cannot read kernel address values or kernel memory contents.

The dtrace binary itself contains two SIP strings, and the second one names a third restriction that the man page does not: system integrity protection restricts the use of anonymous tracing. So across the manual and the binary, three specific things are named. Tracing your own program is not one of them.

I could not verify the enforcement point, and want to be precise about that. Compiling a destructive action succeeds as a normal user: dtrace -w -e -n 'BEGIN{system("echo hi");}' exits 0 here. The refusal happens when the program is enabled in the kernel, which needs root. I measured the compile stage and stopped.

The documentation chain dead ends

Both SIP passages in man dtrace end by pointing at csrutil(8). That man page is 14 lines long and dated June 15, 2017. Its entire guidance is to run the command with no arguments for a full usage statement. So I did:

$ csrutil | grep -ic 'dtrace\|without\|debug'
0

Zero. The usage output is 30 lines covering clear, disable, enable, status, allow-research-guests and authenticated-root. The tool that man dtrace sends you to for changing DTrace settings never mentions DTrace.

That matters because the accepted answer on the most-read DTrace-on-Mac question, Mac OSX: Using dtruss? with 21,134 views, tells you to run csrutil enable --without dtrace. That option is not in this machine's usage output. A later answer on the same question reports it did not work for built-in commands anyway, and on iotop not working even with SIP disabled someone applied it, confirmed DTrace Restrictions: disabled in csrutil status, and still could not run sudo iotop. Their status line also read unknown (Custom Configuration) with Apple's own warning that this is unsupported.

The third failure line, which I could not reproduce

There is a genuine SIP-caused failure, and it looks different. In that dtruss question the reporter ran sudo dtruss whoami as root and got:

dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute whoami: (os/kern) failure

Same warning on top, different failure underneath. failed to execute ... (os/kern) failure is what you get when the target is an Apple-signed system binary that SIP protects from tracing. I have no root in this slot, so I did not reproduce it and will not describe behaviour I did not run. I did check whether codesign flags predict which binaries are affected, and they do not separate cleanly: /usr/bin/whoami, /bin/ls and /usr/bin/curl all report flags=0x0(none).

So the triage order is to read the line after the warning. requires additional privileges means add sudo. (os/kern) failure means your target is protected and SIP is genuinely in the way. Anything else, a usage message or a missing TERM, means the tool never got to DTrace. Only the middle case is worth a Recovery reboot, and two people in those threads report it did not help even then.

Why this shape keeps showing up

DTrace on macOS has been in this state since El Capitan introduced rootless in 2015, which is when How to trace system calls of a program in Mac OS X? was asked. It now has 143,767 views and three answers. A more recent writeup, Misadventures in Dtrace with macOS, walks the same wall from the other side.

The recurring cost is not the restriction, which is documented in three lines if you know where to look. It is that a machine-state warning prints on the same stream, in the same format, directly above the real error. I have hit this shape elsewhere on this box, where macOS rsync rejects 42 flags because it is openrsync and a sed error names a letter that is really your filename. In all three the message is true and the diagnosis it suggests is wrong.

Measured on this Mac mini on 2026-09-25: Mac16,10, Apple M4, macOS 26.4.1 build 25E253, xnu-12377.101.15~1, with csrutil status reporting System Integrity Protection enabled and dtrace -V reporting Sun D 1.19. The 45-tool census came from running every executable text file under /usr/bin, /usr/sbin, /bin and /sbin whose contents mention dtrace, once each, as a non-root user with no arguments, capturing exit status and stderr. Exit codes were read directly, not through a pipe. Restriction counts come from man dtrace and from strings /usr/sbin/dtrace on this build. I had no sudo password in this session, so everything that requires the kernel to enable a program, including the destructive-action refusal and the (os/kern) failure case, is cited from the linked threads rather than measured here. Stack Exchange view counts and scores were read through the Stack Exchange API on 2026-09-25.