views:

48

answers:

2

Here's the hypothetical scenario: I'm running a test script on some hardware attached to box A, which I have root access to. This test script requires minimal user input (flip a switch every half hour or so). About an hour and a half into the test process, I realize that this script takes a long, long time to finish, to the tune of eight hours. Box A is located in a very cold, loud server room that is generally not that fun to physically occupy. Box B is located in my office, where I have a nice comfy chair and an endless supply of hot pockets. I want some way to monitor the output of the process running on box A from an ssh session in box B so I know when to go flip the switch, but I don't want to restart the testing process. Had I known to start with that the test would take so long to finish, I would have just piped its output to a log file and tail'd that file from my box B ssh session. If I know the PID of the process running on box A, is it possible to observe the stdout of that process from another session?

Of course, I could just run vnc on box A and log in from box B to take a look at the output, but that defeats the purpose of this hypothetical, which is to learn more about how process pipes, stdout, and output in general work in a Linux environment.

Thoughts?

+1  A: 

http://ingvar.blog.linpro.no/2010/07/10/changing-a-process-file-descriptor-on-the-fly/

Maxim Yegorushkin
This is exactly what I was hoping to find! Thanks- I hadn't even considered using gdb to hijack the process' file descriptor.
Jordan Wills
A: 

You might want to check out expect It is useful for automating these kinds of interactions.

You could also redirect output of the script to file and monitor said file from another ssh session. I bet the brainy guys on stackoverflow can name about 6 other ways to do it too. :)

SDGuero