I've found dtrace to be an invaluable tool for debugging and troubleshooting all sorts of issues, not to mention the two dozen dtrace toolkit scripts shipped by Apple as part of El Capitan.

On El Cap though, running dtrace usually results in an endless spew of errors making dtrace all but useless.


System Integrity Protection in 10.11 can be disabled, though it's not something you should do lightly.

You can disable SIP entirely by doing the following:

  1. Reboot your mac
  2. Hold ⌘R during reboot
  3. From the Utilities menu, run Terminal
  4. Enter the following command
csrutil disable

Alternatively you can re-enable SIP while still allowing dtrace to work by also running the following:

csrutil enable --without dtrace

Note, that when doing so you'll get the following warning:

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Once you reboot, dtrace will work as it did in Yosemite.

  • Well done - I missed this post when answering the other thread :-) I am going to re-plug Rich's session video and blog: derflounder.wordpress.com/2015/10/01/… – bmike Dec 8 '15 at 16:51
  • 3
    This isn't quite true. With DTrace enabled via csrutil you can invoke the kernel's DTrace - but only on binaries that do not have the restricted entitlements flag. You cannot remove the restricted entitlements flag, even as root, with all of SIP turned off. This means that with DTrace enabled you can DTrace non-system binaries only. However, if a non-system binary uses a shared-lib installed in the system folders (which a lot of programs do), you can't DTrace that either. So the only way to get dtrace to work 'like it did in Yosemite' is to make a copy of all your system folders, and chroot it – J.J Dec 11 '15 at 14:57
  • @J.J what exactly does --without-dtrace do? How would it function if all the binaries still have the restricted entitlements flag set? Do you know if --without-dtrace leaves any security hole? Thanks – Nick Mar 29 '20 at 5:13

Copy the binary to a directory that is not "restricted", for example, /tmp

csrutil disable does not work for dtruss to some degree. But as @J.J said chroot works, this inspired me.

Still I don't know why this works. It may have something to do with the "protected directories", I guess.

Here is the test:

CC@~ $ csrutil status
System Integrity Protection status: disabled.
CC@~ $ sudo dtruss /bin/echo
dtrace: failed to execute /bin/echo: dtrace cannot control executables signed with restricted entitlements
CC@~ $ cp /bin/echo /tmp
CC@~ $ sudo dtruss /tmp/echo

SYSCALL(args)        = return
thread_selfid(0x0, 0x0, 0x0)         = 46811 0
csops(0x0, 0x0, 0x7FFF51B6CA20)      = 0 0
issetugid(0x0, 0x0, 0x7FFF51B6CA20)      = 0 0
shared_region_check_np(0x7FFF51B6A918, 0x0, 0x7FFF51B6CA20)      = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF51B6BEA8, 0x7FFF51B6CA20      = 0 0
  • Do you have a list of “restricted directories”? Or is it in the file system? – Franklin Yu Jun 14 '20 at 3:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .