Comment by PreInternet01 | Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

Parent Full thread

> I wonder though, do people not strace programs any more?

No, I'm pretty sure they don't, and never really have to begin with. Any time I break out strace (or Process Monitor, mainly for Windows, although there's a pretty neat Linux version as well these days), people look at me a bit funny, and conversations starting with "so, this process that keeps crashing because it can't find a file, did you trace the OS calls to see which file that actually is?", pretty much always devolve into a crash course in using this mysterious class of tools.

It's also quite hilarious to see how subtly broken things often are at a low level, and how difficult it sometimes is to work around the resulting performance damage in your language's standard library. Insights like "hmm, maybe I should not explicitly probe for all my secret debug (file/Registry) options, but enumerate all objects in a given location and then compare them internally instead" are also quite common. Not that I mind other people making that "mistake", mind you, as it's often pretty helpful...

> "so, this process that keeps crashing because it can't find a file, did you trace the OS calls to see which file that actually is?"

This is 87.53% of all my uses of strace!

A "fave" of mine is that library loading on both Windows and Linux won't tell you if a dependency of a library is missing, which dependency it is. So you load libfoo and get a "file not found" error - but for which file?

At least on Windows the solution is easy, https://www.dependencywalker.com/

You mean dlopen/dlerror?

My two favorite uses is finding which files a program opens,and looking for pathological uses of write/read. The former to debug failures, the latter has helped speed up so much IO heavy code where people clearly failed to realise the cost of not doing userspace buffering.

> No, I'm pretty sure they don't, and never really have to begin with

I use strace relatively frequently for troubleshooting. It become harder nowadays because modern software tends to do much more syscalls but with filtering it still helpful (many of syscalls I see are not necessary or overused, like calling gettimeofday in a tight loop; developers further and further away from OS and many don't even know what syscall is). Having said that I know developers who tried to minimize number of syscalls they software does (to improve performance) and used tracing as a way to ensure that the software does only what it needs to do.

Interesting, when I have a program crash or fail on me and their logs or other mechanisms are not immediately useful I tend to strace the situation. Understanding what kind of thing it failed during is usually quite simple to understand unless it's a super concurrent system. But even then you can often figure out what triggered the condition.

That is assuming it's reproducible.

I kinda «never» use strace, even after learning about it «annoyingly late». I find myself often in a container which has zero tools / no access to run strace/perf/… or on a win10/mac laptop with no strace. Would be great if someone made a general solution to this «too locked down container» problem.

You don't need to be in the container and trace from there, you can run strace outside of the container (you just have to make sure that the process ID you use is the one as seen from the host).

Not in managed kubernetes / container service cloud thing.

And on docker desktop on mac/win it’s at least some hassle to get into that hidden VM (but let me know if I’m wrong)

On linux-no-vm-bs it’s fine, sure!

You can spawn a (priv) container with the host PID namespace and then trace from there.

strace is useless for containers, you cant attach across container boundaries, and usually you can't install it into the container, either. Which is really sad because its such an useful tool.

Not really, you can start it from the host and trace any container process you like. On Linux the processes are in one large tree and the host has IDs for all container processes. Inside the container you may have different IDs if a pid namespace is used but from the outside these processes are in the host's process tree and have regular IDs.

And “pstree -n PID” can help a lot with this.

Reply on news.ycombinator.com