Except not on MacOS. Lots of tracing is denied by System Integrity Protection; you can use Instruments.app [0] but it doesn't lend itself as well to quick exploration in my experience.
[0] - something like: `xctrace record --template 'System Trace' --launch -- /bin/ls`, then open the trace with Instruments.app.
Mind=blown. Of course! I've been neglecting this thing for so many years!
Question: any recommended reading for using strace effectively?
`run_my_build.whatever` -> hangs, damn.
`strace run_my_build.whatever` -> awesome i can see all the system calls so i know what `.so`s it's pulling in, and what config files it's trying to read, and if it's hanging on a network socket or whatever. This is usually where `strace` just immediately solves my problem.
If you've got like a background daemon that's misbehaving you can do `strace -p <PID>` and it will attach and start printing out the syscalls, this can also be really useful.
`strace` (on all my systems at least) logs to `STDERR` by default, so sometimes you want some combination of like `2>/tmp/log.strace.blah` or to interleave the `STDOOUT` of the process so it's just the usual shell stuff `strace whatever 2>&1 | rg -C ...`.
My use of the tool is very basic, but that's part of what makes it such a great tool, a few simple invocations will just save your bacon. This is especially true on a new team/company or whatever where you run the thing from the Wiki and it doesn't build or start or...
I only know like 10% of the tool and it’s just indispensable. Use strace!!!!!!!