If you use SshExe.RunCommand(string command, ref string StdOut, ref string StdErr) to execute a command that gives sufficiently long output (doesn't appear to be a fixed limit at the moment), then the function will hang. The problem is related to reading the contents of STDERR - if nothing is received and STDERR stays open, the read loop will never return.
I've spent some time trying to fix this, but don't know enough about the details to figure out why this is happening. At the moment I've written a new version of RunCommand which returns the command return code, but doesn't use STDERR, but I would like to be able to fix the problem properly.
My suspicion about what's happening is this: if the output is short enough that all of the STDOUT output is buffered before the code finishes reading it, the remote side will have closed STDERR, which stops it reading anymore. However, if the output is large enough that any receive buffers are full, the code has to process some data before the remote side closes STDOUT/STDERR. However, the line to read data from stderr will not return if no data has been received, or if the channel has not been closed.
The code is stopped here in RunCommand...
while (true)
{
if (o != -1) o = stdout.Read(buff, 0, buff.Length);
if (o != -1) sbStdOut.Append(Encoding.ASCII.GetString(buff, 0, o));
if (e != -1) e = stderr.Read(buff, 0, buff.Length); // THIS LINE NEVER COMPLETES
if (e != -1) sbStdErr.Append(Encoding.ASCII.GetString(buff, 0, e));
if ((o == -1) && (e == -1)) break;
}
The loop that doesn't complete is in PipedInputStream.read() - m_in is set to -1 and never gets incremented as no data is received.
Here's some sample code to illustrate the point:
string sStdOut = "";
string sStdErr = "";
SshExec ssh = new SshExec("78.129.160.6", "root", "host85");
ssh.Connect();
int nRet = ssh.RunCommand("dd if=/dev/zero bs=1000 count=100", ref sStdOut, ref sStdErr);
// We'll never get to this point as the previous command fails.
I see same behavior but for line o = stdout.Read(buff, 0, buff.Length);
Sometimes this happens for very short command which don't return anything.
Appears that for me this happens only for sudo commands. Removing sudo - fixes the problem, but i still need to run command with sudo.
Correction for my comment from 2009-10-10 05:19:
Reason for failure was misconfigured sudoers file. Shell just waited for entering password to run command.
I've added a hack to fix this:
https://sourceforge.net/tracker/?func=detail&aid=3165963&group_id=190927&atid=935325
It's not pretty and I'm not even sure it works for every case, but it solved our issues with long outputs and I've tested it with a long grep command and it seemed to be OK.
Hopefully this is fixed properly in a later release (if there ever will be one?)