| |||||||||||||
Announcing a new utility: 'trace'Announcing a new utility: 'trace'Posted Nov 17, 2010 15:38 UTC (Wed) by Yorick (subscriber, #19241)Parent article: Announcing a new utility: 'trace' I often find myself staring at a line in a very long strace output, wondering where that file descriptor came from. It would be handy to have an option adding this as an annotation, like read(17, "groo", 4) = 4 # 17 = /etc/frotz, O_RDONLY write(9, "moo", 3) == 3 # 3 = tcp 192.88.15.36 port 1469This could probably be done by postprocessing (s)trace output, but it would be handy to have it built in.
(Log in to post comments)
Announcing a new utility: 'trace' Posted Nov 17, 2010 16:21 UTC (Wed) by dvhart (guest, #19636) [Link]
That's an excellent idea.
Announcing a new utility: 'trace' Posted Nov 17, 2010 17:00 UTC (Wed) by hp (subscriber, #5220) [Link]
I could have used this many many times, nice idea.
Announcing a new utility: 'trace' Posted Nov 17, 2010 18:24 UTC (Wed) by ilmari (subscriber, #14175) [Link]
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).
Announcing a new utility: 'trace' 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]
<aol>
I've done this *so* many times...
Announcing a new utility: 'trace' Posted Nov 19, 2010 17:13 UTC (Fri) by adamgundy (subscriber, #5418) [Link] this is the most annoying thing about using strace.. this one feature would be a massive improvement.
Announcing a new utility: 'trace' Posted Nov 19, 2010 17:15 UTC (Fri) by adamgundy (subscriber, #5418) [Link] actually, what would *really* good would be if trace (or strace) could figure out the FD *even if* it didn't see it opened (ie: you attached to the process later on) - combining a bit of lsof functionality with the tracer.
Announcing a new utility: 'trace' Posted Nov 26, 2010 15:37 UTC (Fri) by i3839 (guest, #31386) [Link]
That's fairly easy because all you need is to read the /proc/$PID/fd/$FD symlink. That works great for files. For sockets it works less great, because it seems tricky to figure out which socket belongs to which fd.
|
|||||||||||||