On Thu, Feb 11, 2010 at 10:53 AM, Simon Smith <
address@hidden> wrote:
> Hi -
>
> I'm seeing that whenever I do (via fabric) run("ls") on a remote system, I
> often don't get the last line of output (I do get the output if it is just
> one line)... I can work around it by doing "ls && echo" (i.e. every time I
> care about the output, I'll need to do this) but it seems like quite a hack
> for a very basic and important piece of functionality.
>
>
> I can reproduce this with other commands, like run("cat /some/file").
>
> When I manually run this, e.g. "ssh remotehost ls" I get all of the output.
>
> Am I missing something basic here, or is my issue the same as the one below
> or a different bug?
>
>
> Simon
>
>
>
>> Jeff Forcier wrote:
>
> We've gone back and forth on that particular race condition a number
> of times at this point, unfortunately, so I'm not convinced that this
> change won't introduce other problems. If you dig through the history
> of Fabric from 0.1.1 backwards, looking at
> fabric.py::_start_outputter(), you'll see what I'm talking about. (I
> don't _think_ I changed that part of the code when I created
> magic-removal/0.9; certainly it is by and large untouched.)
>
> I'd be happy if it was this simple but as I said, we've been burned a
> number of times when tweaking this particular chunk of code, so I am
> loathe to just slap another patch on.
>
> -Jeff
>
> On Tue, May 26, 2009 at 4:10 PM, Evan Jones <address@hidden> wrote:
>> Jeff Forcier wrote:
>>>
>>> In the meantime, though, as I said -- if you could try switching your
>
>>> host list around, or simply running this a number of times in a row
>>> and see if any obvious patterns appear, that might help. Feel free to
>>> throw debug statements into fabric.network.output_thread() to see what
>
>>> might be going on, too, as that's inevitably how I'll be debugging on
>>> my end if I need to :)
>>
>> channel.recv_exit_status() can return before output gets written. In fact,
>
>> tracing Paramiko, the message saying "exit status = x" *always* arrives
>> before the message saying "output = y". The main thread then calls
>> channel.close(), which discards any future output. So this is basically a
>
>> classic thread race condition. The attached patch fixes this.
>>
>> Evan
>>
>> --
>> Evan Jones
>>
http://evanjones.ca/
>
>>
>>
>>
>