Re: [Fab-user] Dropped output messages?

[Jeff Forcier]

Hi Evan,

Apologies for the delay; I finally found the time to double check
this. It's definitely a problem (and I wonder why I didn't notice it
before...) and your fix definitely fixes it.

As I mentioned, I'm pretty apprehensive that some *other* issue will
now bite us in a few months, but I looked back at the last few changes
to this part of the codebase (specifically b9a7c9df) and the suggested
change doesn't entirely revert them -- so hopefully this is the last
of it.

I've just pushed a version of your patch (had to extend the fix to
sudo() too) as 7e7fd8a. Thanks for catching this and submitting the
patch!

Regards,
Jeff

On Tue, May 26, 2009 at 4:19 PM, Jeff Forcier<address@hidden> 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/
>>
>>
>>
>