1

When running some intensive debugging that needs to run on the order of about 5 minutes, I'm finding that dtrace's deadman switch is being triggered regularly and cannot get to the error that is being tracked:

dtrace: processing aborted: Abort due to systemic unresponsiveness

It appears that I could modify the parameters of deadman with perhaps dtrace_deadman_timeout being the most promising. These can be found here and the slide is as follows:

dtrace slide

What is the appropriate way to set such parameters on macOS (specifically 10.13.x)?

1

I've had the same issue. I don't know if it's encouraged, but you can use the "-w" flag to "allow destructive actions." This seems to have fixed the issue for me. However I have no idea what the consequences are. I'm running a very simple script though, so I'm reasonably confident that I'm not doing anything that is very "destructive."

This was hard to find, it was a pdf of slides of a presentation given on dtrace and I get the feeling that MacOS only begrudgingly allows basic DTrace support these days. This is too bad because DTrace is an incredibly powerful tool.

For the sake of any poor soul who wanders here with similar issues, the official DTrace book is really helpful and while it doesn't have all the answers, it has probably most of them.

  • This is very useful, thanks for pointing it out. Are you aware of a way to force scripts like dtruss to run with this? I'd hoped that something like sudo dtrace -w /usr/bin/dtruss /bin/ls could force this, but it seems as though the script itself invokes dtrace so it must be modified inside - yet that's not "readily" visible in terms of how to change the invocation options... – ylluminate Jun 1 at 1:22

You must log in to answer this question.

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