Take the 2-minute tour ×
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.

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?

share|improve this question
    
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
add comment

3 Answers

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?

share|improve this answer
    
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
add comment

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
share|improve this answer
    
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
add comment

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

share|improve this answer
    
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
add comment

Your Answer

 
discard

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