Re: [Fab-user] Dropped output

[Jeff Forcier]

Hi Simon,

What version of Fabric are you using? I haven't heard any complaints
about this for some time so I'm hoping the issue has been resolved. I
assume it's the same issue as this one:

    http://code.fabfile.org/issues/show/32

which looks to have been solved with a patch that landed prior to
0.9.0's release. If you're using 0.9.0 and still encountering the
problem, let me know and we can continue.

Best,
Jeff

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/
>
>>
>>
>>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>



-- 
Jeff Forcier
Unix sysadmin; Python/Ruby developer
http://bitprophet.org