2

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
    The easiest way would be sending strace output to a file and use tail -f in the other window. – ott-- Sep 17 '16 at 12:13
3

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).

  • This 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 Sep 17 '16 at 15:05
  • Agreed. I'll edit my answer. – Eirik Fuller Sep 17 '16 at 15:06
  • Actually it can kinda sorta work, though would require a small wrapper that reveals the pid, waits for strace to start or on some other signal then execs the program proper. – thrig Sep 17 '16 at 15:08
  • A wrapper seems unlikely to easily fulfill the goal of using separate windows for strace and the process whose system calls it reports. – Eirik Fuller Sep 17 '16 at 15:14
2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.