I have an application running on a server, started from the command line. From time to time, I need to connect to the server via SSH and get the output messages written to stdout from the application. Is there a way to read/sniff/catch the messages on that terminal? The server runs Fedora 12.

To clarify a bit more. I have admin access to the server, but I cannot stop the running application because it is in critical environment. It is the end user who starts the application from a terminal. Via ssh I have to read messages in the terminal whenever user sees strange behaviors. It is a graphical application. I may build a script to run the application with screen, this means I have to change the "launcher" but there are some servers not always accessible for security reason from outside the LAN. Updating is complicate. My question is, if there is an application running, is there any way to catch its output in the terminal without stopping it and rerun under screen or whatever?

  • Ok, I see the situation better now. I'd still like to know more. The reason you can't change the launcher is more usability than security, right? Do you have root access to the machine, or only access as the user running the application? Is the application running on a text console, or in a terminal emulator under X (you mention that it's graphical)? Can you make changes to /etc or /usr if it turns out to be useful? Do you need a history of all messages, are you ok with the last few before you connected, or is it enough to see the new messages from after you ssh'ed in? – Gilles Dec 11 '10 at 13:51
  • there are some deployed servers which is almost impossible to change the launcher now.I have root access when customer temporary gives me ssh connection for maintenance (setting firewall, open vpn, etc). Application runs under X. I can take any changes in the server but I need special customer authorization to stop the running application. This is a big problem. It is a security tool. I would need, let us say the last 50-100 messages before I connect. – Luke Dec 11 '10 at 14:07

The obvious solution would be to redirect the application's output to a file, and look at that file:

nohup application >app.log &  # on the server
ssh server tail -n +1 -f app.log   # on the client

If the application must have its output in a terminal, run it in screen.

On the server:
screen -S somename -Rrd
press Ctrl+A D to “detach” from the screen session, leaving it running in the background

From the client:
ssh server
screen -S somename -Rrd to reconnect to the screen session

If you want messages to be recorded automatically, the best way is to use the standard log facility. You can arrange for log entries to be sent to other machines, either crudely with most basic syslogs, or with better filtering and dispatching options with rsyslog.

  • In my case I cannot start the application on the server with screen approach.Yes, application must have its own output in the terminal. I cannot stop and restart the application. – Luke Dec 11 '10 at 9:02

I think that in this case better than redirection output to file is redirect it to named pipe (fifo), because there is no need to store all data on disk. If program produces a lot of output we could run out of disk space.

Instead of a conventional, unnamed, shell pipeline, a named pipeline makes use of the filesystem. It is explicitly created using mkfifo() or mknod(), and two separate processes can access the pipe by name — one process can open it as a reader, and the other as a writer.

mkfifo /path/to/my/pipe
someprogram > /path/to/my/pipe
tail -f /path/to/my/pipe

If you want to output it also to stdout you could use tee:

someprogram | tee /path/to/my/pipe
  • If the program produces a lot output, it's long-running, therefore sending to a pipe is a bad idea. If there's nothing listening on the pipe, this will block the program, or kill it due to a broken pipe. So when you pipe the program's output, you promise that the program you're piping into will live forever. That's not a tenable assumption here, where the program you're piping into is dependent on an ssh connection in a terminal on a client machine. – Gilles Dec 10 '10 at 21:18
  • Yes, it is a long-running program which writes debug messages in a terminal. When some problem is reported then I need via ssh to connect to server and should be able to catch the latest messages in the terminal for problem resolution – Luke Dec 11 '10 at 9:06

I am looking for a solution which does need to start server in a special way because I am not allow to start the program and cannot even stop and restart in a special environment. Someone starts program on the server and I have to check message output in the terminal when there are troubles. Any idea how to achieve?

  • Since you're clarifying your question and not answering it, please edit your question, and delete this answer. – Gilles Dec 11 '10 at 12:23
  • If the server is not started in a special way, what is its output connected to? A physical terminal? If you don't have the permission to start the program, you probably don't have the permission to access that terminal either, otherwise you could type into it and start the program. Maybe if you describe very precisely what the program is and how it's started someone will find a way for you to see the output, but the way you've described it so far, it looks like you're not supposed to be able to see it. – Gilles Dec 11 '10 at 12:26
  • Right Gilles....Let me add more info. – Luke Dec 11 '10 at 13:35

Your Answer

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