I've used both depending on the situation - I am a huge fan of strace (especially 'strace -f') and have done some truly stupid shit with it. Best example being

I've used both depending on the situation - I am a huge fan of strace (especially 'strace -f') and have done some truly stupid shit with it. Best example being dealing with a situation where a client's code could only have one connection to a particular external streaming API they were using and the developer in charge of connecting to it was a tad territorial and wouldn't provide me a way to access the data that actually worked for the task I'd been assigned. Solution: strace his process with a -s argument that was larger than any read his process ever did, then backprocess it into the original bytes on the wire, then handle them myself. Yes, this was a horrible hack, but it allowed me to prove the concept of the thing the client wanted building without causing massive political drama that would've been more trouble for everybody involved than it was worth. Ideal for that sort of situation would (for me) likely be trapping the open and close functions and having them emit information to stderr while -also- having strace log to the same stderr so I could see how the two compare - with the caveat that whether it's viable to do that is highly variable depending on context. But as a last comment on strace, I present an old entry from my quotefile: <@mst> actually, I think my first thing to try would be to strace the code <@mst> and try and match up the new value of $! with a failed syscall <@mst> but I mean if strace was a person I'd totally be asking them out to dinner so maybe I'm biased