strace is basically my first go-to when a command immediately fails with an obscure message.<p>strace, skim the last 4-5 pages of trace output before the error message is emitted, looking in particular for error return values (it's often not <i>right</i> before the error because the program has started to clean up). Figures out the problem 80% of the time within a couple of minutes.
The widespread switch to epoll(7)-based I/O systems has taken a big bite out of strace's usefulness for me.<p>Back when most programs did most of their I/O synchronously or with select(2)/poll(2), it was really easy to use strace to track down slow network services. If you wanted to figure out why a process was taking too long, you could strace it, grab the file descriptor numbers that it was spending a long time reading/writing/selecting/polling, feed those into lsof and turn them into network addresses/ports, then shell into those remote hosts and see what it was doing with the slow client's connection (e.g. if the remote host was a MySQL database you could check what queries were running on its connection/session; if it was a RabbitMQ you could see what queues its connection was operating on).<p>Don't get me wrong: strace is still an incredibly useful tool every Linux developer, no matter where they are in the stack, should know (Julia Evans made that case better than I could[1]). I also understand why I/O systems switched to more "file descriptor opaque" tools like epoll/kqueue/io_uring, which makes sense and brings a lot of benefits. I just miss the transparency of the old APIs a little bit, you know?<p>1: <a href="https://jvns.ca/blog/2014/04/20/debug-your-programs-like-theyre-closed-source/" rel="nofollow">https://jvns.ca/blog/2014/04/20/debug-your-programs-like-the...</a>
I hated macOS for gating / crippling dtruss with SIP every time I need to find out what’s wrong with a random cmd.<p>Is there any alternatives on Mac?
Oh boy, strace is soooo useful, and not just for coding or sysadmin.<p>As a <i>user</i>, when e.g. my browser does funky stuff like freezing for no reason, my knee-jerk reflex is always strace.<p>I was initially a little put down by the russian style moody intro (the longish "why would you use such an antiquated thing as strace in 2023" which made me think he was going to tear down strace), but stick with the video past it, it is actually an ode to strace and it's well worth it.<p>Personnaly, I never realized strace had this many features.
Talking about strace per the title without watching; wow is strace ever helpful!<p>You can build an ordered tree of all the programs launched by a program, recursively, using strace. You can do the same for observing files opened. It's an amazing tool when you need to observe some software from the outside; in many ways it'll give you much better understanding of a program than even reading it's source code.
In emacs you can use syslog-mode for analyzing strace output: <a href="https://github.com/vapniks/syslog-mode">https://github.com/vapniks/syslog-mode</a>
It allows you to easily navigate, filter, highlight lines, and lookup documentation.
The safer/non-slowing down alternative for tracing syscalls would be "perf trace" (and eBPF scripts), but I've found in past that perf trace didn't decode enough syscall arguments (and just listed pointers to structs, where strace showed the info inside these structs). But I just ran a few simple "perf trace" commands on RHEL 9, looks like it has caught up somewhat.
He mentions all these other ways of doing tracing and I assume he means eBPF, but I've yet to see anything useful I can run from the CLI to use that.<p>So what is there out there? Because I'm a veteran Linux/Unix sysadmin for 25 years now and I love strace when I'm in a bind.<p>So what should I look at now based on eBPF instead?