Using a SSH library to connect to unix and tail a file: Is this the right approach?

Question

As Ive stated with a few other questions, Ive been using a new SSH .NET library to connect to a Unix server and run various scripts and commands. Well, I've finally attempted to use it to run a Unix tail -f on a live log file and display the tail in a Winforms RichTextBox.

Since the library is not fully-fleshed out, the only kinda-sorta solution I've come up with seems lacking... like the feeling you get when you know there has to be a better way. I have the connection/tailing code in a separate thread as to avoid UI thread lock-ups. This thread supports cancellation request (which will allow the connection to gracefully exit, the only way to ensure the process Unix side is killed). Here's my code thus far (which for the record seems to work, I would just like some thoughts on if this is the right way to go about it):

PasswordConnectionInfo connectionInfo = new PasswordConnectionInfo(lineIP, userName, password);

string command = "cd /logs; tail -f " + BuildFileName() + " \r\n";

using (var ssh = new SshClient(connectionInfo))
{
    ssh.Connect();

    var output = new MemoryStream();
    var shell = ssh.CreateShell(Encoding.ASCII, command, output, output);

    shell.Start();

    long positionLastWrite = 0;

    while (!TestBackgroundWorker.CancellationPending) //checks for cancel request  
    {
        output.Position = positionLastWrite;

        var result = new StreamReader(output, Encoding.ASCII).ReadToEnd();
        positionLastWrite = output.Position;
        UpdateTextBox(result);

        Thread.Sleep(1000);
    }

    shell.Stop();
    e.Cancel = true;
}

The UpdateTextBox() function is a thread-safe way of updating the RichTextBox used to display the tail from a different thread. The positionLastWrite stuff is an attempt to make sure I don’t loose any data in between the Thread.Sleep(1000).

Now Im not sure about 2 things, first being that I have the feeling I might be missing out on some data each time with the whole changing MemoryStream position thing (due to my lack of experiance with MemoryStreams, and the second being that the whole sleep for 1 second then update again thing seems pretty archaic and inefficient... any thoughts?

score 1 · Accepted Answer · edited May 23 '17 at 10:29

1

Mh, I just realized that you are not the creator of the SSH library (although it's on codeplex so you could submit patches), anyway: You might want to wrap your loop into a try {} finally {} and call shell.Stop() in the finally block to make sure it is always cleaned up.

Depending on the available interfaces polling might be the only way to go and it is not inherently bad. Whether or not you loose data depends on what the shell object is doing for buffering: Does it buffer all output in memory, does it throw away some output after a certain time?

My original points still stand:

One thing which comes to mind is that it looks like the shell object is buffering the whole output in memory all the time which poses a potential resource problem (out of memory). One option of changing the interface is to use something like a BlockingQueue in the shell object. The shell is then enqueuing the output from the remote host in there and in your client you can just sit there and dequeue which will block if nothing is there to read.

Also: I would consider making the shell object (whatever type CreateShell returns) IDisposable. From your description it sounds shell.Stop() is required to clean up which won't happen in case some exception is thrown in the while loop.

edited May 23 '17 at 10:29

Community

1
1

answered Jun 30 '11 at 19:46

ChrisWue

18,612
4
58
83

Well the library has a custom memory stream it uses called PipeStream and the creator makes it sound just like the BlockingQueue you describe, check this out if you get the chance: http://sshnet.codeplex.com/discussions/263452 – Hershizer33 Jun 30 '11 at 20:24
@Hershizer33, `PipeStream` looks like it is what you want. Although the implementation of `ReadAvailable` seems a bit weird: It always requires the buffer to have at least `count` bytes to read or being flushed. – ChrisWue Jun 30 '11 at 23:16
Using PipeStream has brought some issues... seeems to loop forever in the Read function of its code, only reason I can think of why is that since the log file is streaming so quickly, it always has data to read, and just keeps on reading... any thoughts? – Hershizer33 Jul 01 '11 at 18:46
1

Try without the `StreamReader` and use the `Read` method of thestream directly and see what you get with this. – ChrisWue Jul 01 '11 at 21:00
That seemed to work, just worried about potential data loss now... the inside of my loop looks like this now: `byte[] tempBytes = new byte[output.Length]; output.Read(tempBytes, 0, tempBytes.Length); System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding(); string result = enc.GetString(tempBytes); UpdateAP2TextBox(result); Thread.Sleep(1000);` I figure since this is supposed to delete what it reads, its okay to always start reading at 0 to Length – Hershizer33 Jul 05 '11 at 13:32
Yes, it queues the data and dequeues them when you read so you should not loose any data. You also don't need the `sleep` - the stream should block on read if the queue is empty. – ChrisWue Jul 06 '11 at 02:31

Using a SSH library to connect to unix and tail a file: Is this the right approach?

1 Answers1