Tip for anyone reading: If you only need to trace file accesses or command executions, `eslogger lookup` and `eslogger exec` respectively will give you what you need (albeit in the form of a not-particularly-friendly JSON blob).
This triggered a small emotional reaction. I really miss the days when Apple made real effort toward servers with MacOS X Server and Xserve. Hopefully, since they're using their own hardware/software internally for servers, Apple may one day go back down that road.
You need to escalate to root to run it anyway. If anyone can get root on my laptop, there's nothing that SIP can realistically protect me from. Actually, if anyone can get access to my user outside of sandbox, everything I care about is already exposed.
(Also, you can disable it only for dtrace if you want)
Doesn't appear to work, and lacks pypi and brew packaging.
$ pipx install git+https://github.com/Mic92/strace-macos
installed package strace-macos 0.1.0, installed using Python 3.13.7
These apps are now globally available
- strace
done!
$ strace df -h
Error: Failed to load LLDB Python module.
Make sure you're running with system Python (/usr/bin/python3) and have Xcode Command Line Tools installed.
To install Xcode Command Line Tools:
xcode-select --install
$ sudo strace df -h
[same shit]
After fixing[0] the awkward python system requirement, it doesn't work with built-in binaries without SIP disabled, it's really slow, it colorizes output even when piping, and the colors are terrible. Better than nothing but it's currently less effort to temporarily disable SIP for dtruss and reenable it later than install this in this early form. Maybe with time it will improve, but it seems like a vehicle to aggressively advertise consulting services.
It’s working. You deliberately ignored the requirements clearly stated multiple times in the README, which explains that it must use the same version of Python as LLDB because it relies on LLDB's Python bindings. The tool even explained again what you should do instead after you defied the installation instructions, yet you chose to run the same command again with sudo, turning this into a spectacle. This isn’t a software issue. It’s you messing around.
> it seems like a vehicle to aggressively advertise consulting services.
It's an open source tool that addresses a pain point many people have, made with someone's spare time with no strings attached. What is wrong with you?
> it doesn't work with built-in binaries without SIP disabled
You can't debug system binaries on macOS with SIP. That's the whole point of SIP. Debugging user binaries is still very much allowed.
sudo lldb /bin/ls
Password:
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (arm64e).
(lldb) r
error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
> lacks pypi and brew packaging
That's an entitled complaint against a project made just 2 days ago [1], which offers a single line command for installation.
Barely supported by Apple these days - in addition to needing to disable SIP which is a pain, it was broken causing system freezes for several major macOS releases.
Does instruments allow you to track file reads/writes and other syscalls/mach stuff? Their docs are quite bad at describing the capabilities, so I'm not really sure. From what I can see it's a profiler rather than a tracing tool.
For things that run on Linux and other Unices yes.
For macOS UI programs and those that need specific permissions and for commercial programs stick with Homebrew but you can define what you want in homebrew in nix.
Tip for anyone reading: If you only need to trace file accesses or command executions, `eslogger lookup` and `eslogger exec` respectively will give you what you need (albeit in the form of a not-particularly-friendly JSON blob).