We have several application servers, and a central monitoring server.
We are currently running ssh with "tail -f" from the monitoring server to stream several text logfiles in realtime from the app servers.
The issue, apart from the brittleness of the whole approach is that killing the ssh process can sometimes leave zombie tail processes behind. We've mucked around with using -t to create pseudo-terminals, but it still sometimes leaves the zombie processes around, and -t is apparently also causing issues elsewhere with the job scheduling product we're using.
As a cheap-and-dirty solution until we can get proper centralised logging (Logstash and RabbitMQ, hopefully), I'm hoping to write a simple Python wrapper that will start ssh and "tail -f", still capture the output, but store the PID to a textfile on disk so we can kill the appropriate tail process later if need be.
I at first tried using subprocess.Popen, but then I hit issues with actually getting the "tail -f" output back in realtime (which then needs to be redirected to a file) - apparently there are going to be a host of blocking/buffer issues.
A few sources seemed to recommend using pexpect, or pxssh or something like that. Ideally I'd like to use just Python and it's included libraries, if possible - however, if a library is really the only way to do this, then I'm open to that.
Is there a nice easy way of getting Python to start up ssh with "tail -f", get the output in realtime printed to local STDOUT here (so I can redirect to a local file), and also saving the PID to a file to kill later? Or even if I don't use ssh with tail -f, some way of still streaming a remote file in (near) realtime that includes saving the PID to a file?
Cheers, Victor
EDIT: Just to clarify - we want the tail process to die when we kill the SSH process.
We want to start ssh and "tail -f" from the monitoring server, then when we Ctlr-C that, the tail process on the remote box should die as well - we don't want it to stay behind. Normally ssh with -t should fix it, but it isn't fully reliable, for reasons I don't understand, and it doesn't play nicely with our job scheduling.
Hence, using screen to keep the process alive at the other end is not what we want.
I wrote a function that do that:
The paramiko module supports connecting with via ssh with python.
http://www.lag.net/paramiko/
The pysftp has some examples of using it and the execute command method might be what your looking for. It will create a file like object of the command you execute. I can't say if it gives you live data though.
http://code.google.com/p/pysftp/
I know this doesn't answer your questions, but...
Maybe you could try using screen. If your session drops, you can always reattach and the tail will still be running. It also supports multiuser, so 2 users can view the same tail command.
http://en.wikipedia.org/wiki/GNU_Screen
create with the name "log":
disconnect:
reattach
list when you can remember the name
To get rid of the session, just type
exit
while in it.I think the screen idea is the best idea, but if you're not wanting to ssh and you want a python script to do it. Here is a simple pythonic XMLRPC way of getting the info. It will only update when something has been appended to the file in question.
This is the client file. You tell this which file you want to read from and what computer its on.
This is the server you will run this on each computer that has a file you want to look at. Its nothing fancy. You can daemonize it if you want. You just run it, and you client should connect to it if you tell the client where it is and you have the right ports open.
Ideally you run the server once, then from the client run "python client.py sample.log http://somehost:8000" and it should start going. Hope that helps.
I've posted a question on something like this with code (paramiko)
tail -f over ssh with Paramiko has an increasing delay
I've written a library that allows you to do just this - check out the "remote" feature of PimpedSubprocess (on github) or PimpedSubprocess (on PyPI)