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 <addr...@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
Fab-user@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fab-user

Reply via email to