Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have left a script running on a remote machine from when I was locally working at it. I can connect over SSH to the machine as the same user and see the script running in ps.

$ ps aux | grep ipcheck
myuser  18386  0.0  0.0  18460  3476 pts/0    S+   Dec14   1:11 /bin/bash ./ipchecker.sh

It is simply outputting to stdout on a local session (I ran ./ipchecker.sh form a local terminal window, no redirection, no use of screen etc).

Is there anyway from an SSH session I can view the output of this running command (without stopping it)?

So far the best I have found is to use strace -p 18386 but I get hordes of text flying up the screen, its far too detailed. I can stop strace and then sift through the output and find the text bring printed to stdout but its very long and confusing, and obviously whilst it's stopped I might miss something. I would like to find a way to see the script output live as if I was working locally.

Can anyone improve on this? The obvious answer is to restart the script with redirection or in a screen session etc, this isn't a mission critical script so I could do that. Rather though, I see this as a fun learning exercise.

share|improve this question
Is your process running in a virtual console or in a GUI/xterm like environment? – jippie Dec 15 '12 at 15:20
You can limit output of strace to one syscall: strace -p 4232 -e write – otokan Dec 15 '12 at 15:59
@jippie The machine is running a full GUI (Linux Mynt 13, XFCE desktop), I fired up a gnome-terminal. – jwbensley Dec 15 '12 at 16:14
There's at least a dozen of similar questions on this site. Look for reptyr here to find a few of them (and an answer). – Stéphane Chazelas Dec 15 '12 at 22:46

In BSD, you can use watch which snoops a given tty, e.g.

watch /dev/pts/0

In Linux, it won't be possible if the process wasn't run under multiplexer before such as screen or tmux. See also: Reptyr: Attach a Running Process to a New Terminal

It seems the only way is to debug the process (e.g. strace, dtrace/dtruss, gdb, lldb, etc.).

Since you've used strace, to fetch any meaningful output, you need to filter by a qualifying expression (such as file), then parse the output. Here is example:

strace -e trace=write -s1000 -fp 18386 2>&1 | grep -o '".\+[^"]"'

What it does it prints write operation of the process (1000 length) specified by PID (use pgrep to find it by name), redirects standard error into output (to be filtered), and prints double-quoted string.

If you're dealing with binary output, you may parse escape sequences characters by using read (with -r) and printf (with %b), e.g.

while read -r -t1 line; do printf "%b" $line; done

Check help read for more parameters (e.g. -n to print after certain amount of characters, rather than newline).

Here is more complete example:

strace -e trace=write -s1000 -fp 18386 2>&1 \
| grep --line-buffered -o '".\+[^"]"' \
| grep --line-buffered -o '[^"]\+[^"]' \
| while read -r line; do
  printf "%b" $line;

For examples using any process, please check: How to parse strace in shell into plain text? at stackoverflow

share|improve this answer

If all you want to do is spy on the existing process, you can use strace -p1234 -s9999 -e write where 1234 is the process ID. (-s9999 avoids having strings truncated to 32 characters, and write the system call that produces output.) If you want to view only data written on a particular file descriptor, you can use something like strace -p1234 -e trace= -e write=3 to see only data written to file descriptor 3 (-e trace= prevents the system calls from being loged). That won't give you output that's already been produced.

If the output is scrolling by too fast, you can pipe it into a pager such as less, or send it to a file with strace -o trace.log ….

With many programs, you can divert subsequent output with a ptrace hack, either to your current terminal or to a new screen session. See How can I disown a running process and associate it to a new screen shell? and other linked threads.

share|improve this answer
I don't suppose there's a way to narrow down the output to just the standard output? – Jonah Mar 28 '13 at 0:33
Can you explain all the arguments? – User Mar 16 '15 at 22:15
There was a lot of backslashes and numbers in a lot of the output I was getting from nodejs; Any leads on what encoding they might be in? There was plenty of plain text too, which was all i needed. – ThorSummoner Jul 16 '15 at 17:27
@ThorSummoner If you see a backslash followed by three octal digits between double quotes in the strace output, that means a byte whose numeric value is given by the digits. You'll see that for non-ASCII characters. – Gilles Jul 16 '15 at 17:46
@Gilles well, damn. I didn't build the application. So, I guess I'll have to 'dissect' the application. – Rafael Moni Dec 22 '15 at 12:25

can't you get the process ID and communicate with it with USR1,

$pgrep -l '^ipchecker.sh$'

which prints your script's PID, then use it to

$ kill -USR1 PID

I understand that USR1 is a "user defined" signal, meaning that whoever created the program can use it to mean "shut down" or "dump your logs" or "print foo a thousand times" or whatever.

share|improve this answer
  1. You might be able to peek at the remote screen using ssh localhost 'DISPLAY=:0.0 xwd -root' | xwud -scale where localhost is to be replaced by your remote server login credentials and :0.0 with the display number of your GUI.

  2. Use x11vnc, which is a VNC server for your on screen X-session.

  3. When running on one of the 6 virtual consoles try sudo setterm -dump 2 -file /dev/stdout, where you replace 2 with the appropriate vc.

share|improve this answer

I'd advice to make a named pipe (mkfifo) and then write to that file. Then, read from it. You can always do that with things like tail, to minimize output, etc. Whenever you clear the pipe (read from it), it gets cleared, so the output is not preserved.

The other option would be to write everything to a file (much like a logfile) and then analyze it an any time. This would be the preferred action, if you want to preserve all output.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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