Lets say I want to discover how pry works by strace.
Is it possible to redirect the output from strace to another window?
So I can have two windows, one for pry where I'm making all interaction, and another window of strace's output.
2 Answers
You can use strace -p in one window to trace a command running in another window. The -p option accepts one or more process ids, so you could, for example, try
strace -p "$(pidof pry)" if you have at least one process which pidof recognizes as pry. You might need to experiment with pidof (if I want to strace a pudb3 command, I need to use python3 rather than pudb3), and using pidof might not be the best approach if there is any ambiguity associated with it (you might have multiple commands which match but only want to strace one of them). It might be easier to find the right process is with ps and provide the option directly.
This approach is not likely to work well with a short lived process, or in a situation where it's important to see output from early in the lifetime of the process, but for an interactive application whose startup time isn't especially interesting, it might be workable.
One difference with using strace -p as opposed to strace without -p is how interrupts are handled. A process launched by strace will have interrupts like Ctrl-C passed along to it (and reported by strace), but Ctrl-C in strace -p will detach it, and allow the process to continue without tracing (and Ctrl-C still works in the application if it's in a separate window).
- 2This is correct +1, although I'd expand it with a small example. Also, this will work well for REPLs but not that well for programs that run and then exit (you would not be able to catch their PID).grochmal– grochmal2016-09-17 15:05:05 +00:00Commented Sep 17, 2016 at 15:05
- Agreed. I'll edit my answer.Eirik Fuller– Eirik Fuller2016-09-17 15:06:21 +00:00Commented Sep 17, 2016 at 15:06
- Actually it can kinda sorta work, though would require a small wrapper that reveals the pid, waits for
straceto start or on some other signal thenexecs the program proper.thrig– thrig2016-09-17 15:08:47 +00:00Commented Sep 17, 2016 at 15:08 - A wrapper seems unlikely to easily fulfill the goal of using separate windows for
straceand the process whose system calls it reports.Eirik Fuller– Eirik Fuller2016-09-17 15:14:41 +00:00Commented Sep 17, 2016 at 15:14
And the wrapper method for short-lived processes or where it is important to see output from early in the lifetime of the process:
#!/bin/sh # the pid could be sent to a file or named pipe the-thing-that-does- # strace could be watching, though in most cases a human could copy it echo "PID to strace is $$" trap : USR2 # block while human copies pid over to strace (or some program acts on # the above pid being written in that other terminal). Busy loop or # something instead if this program must not consume input (`sleep` # complicates the signal handling) read blocking # then when strace is up, send this process a USR2 signal. this will # mean there will be some strace of this script in addition to the # target, hence the kinda sorta caveat. exec echo /the/program/of/interest Or, instead simply run sysdig in that other terminal window, as sysdig can snoop directly on a program by name:
sysdig -p '%proc.name %evt.type(%evt.args)' \ proc.name contains /the/program/of/interest 
tail -fin the other window.