OH! YES! PLEASE! I have lost count of the hours I've spent groveling through traces to find where an fd came from (and that only works if you have a trace of the entire lifetime of the process, i.e. not when attaching to an already-running one with -p).
Posted Nov 17, 2010 19:49 UTC (Wed) by oak (subscriber, #2786)
[Link]
Preferably also for unix sockets too, not just files. I mean, files are easy see if the process is still running, you just check /proc/PID/fd/ (or use lsof), but for unix sockets it's nearly impossible to see to which unix socket (file) given FD is related to unless you catch also the connect().
As this thing is tracing whole system not just individual process like strace does, it might be too slow to get all arguments to all functions. The arguments to functions like open() etc that return values being used by other system calls, are very important though. For example LTT doesn't store file names for access() calls (one can see them with strace if really necessary), but it will store them for open() calls.
As to formatting of the output, ltrace is quite nice. It aligns the call return values so that they're easier to see + it has separate option for call time and count summaries. Try for example:
ltrace -S cat
^C
ltrace -c cat
^C
Announcing a new utility: 'trace'
Posted Nov 23, 2010 13:58 UTC (Tue) by stevem (subscriber, #1512)
[Link]