Possible pty detection bug

[bitprophet]

Description

IRC user djill_ encounters problems in 1.0 (but not 0.9) when piping Fabric output to tee, e.g. fab [options] [task names] | tee [filename].

This is his traceback:

09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/main.py", line 537, in main
09:32 < djill_>     commands[name](*args, **kwargs)
09:32 < djill_>   File "/home/fabric/fabsys.py", line 15, in date
09:32 < djill_>     run('date')
09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/network.py", line 304, in host_prompting_wrapper
09:32 < djill_>     return func(*args, **kwargs)
09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/operations.py", line 916, in run
09:32 < djill_>     return _run_command(command, shell, pty, combine_stderr)
09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/operations.py", line 840, in _run_command
09:32 < djill_>     combine_stderr)
09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/operations.py", line 726, in _execute
09:32 < djill_>     rows, cols = _pty_size()
09:32 < djill_>   File "/usr/lib/python2.5/site-packages/Fabric-1.0.0-py2.5.egg/fabric/operations.py", line 50, in _pty_size
09:32 < djill_>     buffer)
09:32 < djill_> IOError: [Errno 22] Invalid argument

That says to me that it's a bug in how we try to update the remote pty based on the local one; if one's stdout/stderr is going to a shell pipe and not a terminal, that could definitely be causing that IOError.

Hopefully a quick fix; though given that it's an IOError with "invalid argument" (which is kind of generic) we may need to find a way of testing beforehand and skipping the pty stuff, instead of simply adding a try/catch.

EDIT: Michael Bravo has a similar/same issue when piping Fabric to grep, though his error was IOError: [Errno 25] Inappropriate ioctl for device (on the exact same line). Not sure if that's an argument for or against the test-first vs catch-IOErrors approach...

---

Originally submitted by Jeff Forcier (bitprophet) on 2011-03-07 at 10:25am EST

Attachments

• operations.patch

Relations

• Duplicated by Inappropriate ioctl for device #349: Inappropriate ioctl for device
• Duplicated by Handle running without any controlling tty #197: Handle running without any controlling tty

[bitprophet]

**** (mbravo) posted:

---

here's my traceback (occurs with 1.0.0 when piping output to grep):

Traceback (most recent call last):
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/main.py",
line 537, in main
   commands[name](*args, **kwargs)
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/decorators.py",
line 75, in inner_decorator
   return func(*args, **kwargs)
 File "/Users/mbravo/Documents/mgmt/fabric/playkot/fabfile.py", line
130, in mem_alldb
   run('free')
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/network.py",
line 304, in host_prompting_wrapper
   return func(*args, **kwargs)
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py",
line 916, in run
   return _run_command(command, shell, pty, combine_stderr)
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py",
line 840, in _run_command
   combine_stderr)
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py",
line 726, in _execute
   rows, cols = _pty_size()
 File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py",
line 50, in _pty_size
   buffer)
IOError: [Errno 25] Inappropriate ioctl for device

---

on 2011-03-07 at 02:05pm EST

[bitprophet]

Joel Eidsath (joel@counsyl.com) posted:

---

I see the same issue. Running python 2.6.5 and fabric 1.0.0 on an Ubuntu 10.04 box. The issue seems to come up on all remote hosts that I have tested it on (Ubuntu and Centos). Here's a sample fabfile that reproduces the bug reliably:

from fabric.api import sudo


def test():
    sudo('echo hello world')

Here is the output:

(fabtest)joel@joel-vm:~/tmp$ fab test -H root@science3 | tee output.txt
Traceback (most recent call last):
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/main.py", line 537, in main
[root@science3] Executing task 'test'
[root@science3] sudo: echo hello world
commands[name](*args, **kwargs)
File "/home/joel/tmp/fabfile.py", line 4, in test
sudo('echo hello world')
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/network.py", line 304, in host_prompting_wrapper
return func(*args, **kwargs)
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 944, in sudo
user=user)
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 840, in _run_command
combine_stderr)
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 726, in _execute
rows, cols = _pty_size()
File "/home/joel/fabtest/lib/python2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 50, in _pty_size
buffer)
IOError: [Errno 22] Invalid argument
Disconnecting from science3... done.

---

on 2011-03-17 at 02:43pm EDT

[bitprophet]

Joel Eidsath (joel@counsyl.com) posted:

---

And here's a patch which fixes the problem for me.

---

on 2011-03-17 at 03:07pm EDT

[bitprophet]

Derrick Petzold (derrickpetzold) posted:

---

fyi I also ran into this and the patch fixed it.

---

on 2011-04-06 at 07:18pm EDT

[bitprophet]

Morgan Goose (goosemo) posted:

---

Do you have a branch with said patch in it?

---

on 2011-04-06 at 11:24pm EDT

[bitprophet]

Joel Eidsath (joel@counsyl.com) posted:

---

The inability to do the following seems like a lot bigger problem than just a "wart":

fab somecommand | tee output.txt

How exactly are we supposed to log the results of fab commands? At least change the code to ignore all IOErrors (like patch does) until this can be resolved more gracefully.

---

on 2011-08-17 at 12:21am EDT

[bitprophet]

Jeff Forcier (bitprophet) posted:

---

"Wart" is a designation commonly used to mean "seriously ugly", as in "this is something that stands out to almost all users as very broken or lacking and is a frequent source of frustration". On this tracker specifically, it's used as the highest priority and as an indicator that such issues should be taken care of ASAP if possible.

So switching from Normal to Wart was an upgrade of priority (specifically, it's been reported even more widely lately and is clearly affecting more than a handful of users.)

I understand your frustration, but taking a demanding tone is rarely productive when dealing with volunteers. You'd get way more sympathy from me (and probably others) with "this still affects me and isy making my life difficult -- any update on release? Would it make sense to implement a stopgap solution?" instead of being huffy about it :)

---

on 2011-08-17 at 11:12am EDT

[bitprophet]

Joel Eidsath (joel@counsyl.com) posted:

---

I did not mean to come across as demanding -- written text on the internet rarely communicates our feelings as well as the same words would would over dinner or a pint of beer, and I'd appreciate it if you interpreted mine with a spirit of charity. I wasn't asking anyone to do any work for me and did not mean to be taken that way. I wrote the patch above and apply it on all my builds. The problem is gone for me. It's only an issue for your other users.

As an aside, 'wart' generally means "blemish, or imperfection" unless you are referring to the Papilloma virus. Maybe no one but me will ever be confused by this, but you guys are the only ones the internet with this usage: Google Search: "wart bug tracking"

---

on 2011-08-17 at 12:17pm EDT

[bitprophet]

Jeff Forcier (bitprophet) posted:

---

Joel Eidsath wrote:

I did not mean to come across as demanding

Fair enough. I was keying off the phrases "How exactly" and "At least" which both tend to come across as kind of complain-y. But you're right that text communication tends to confuse things.

you guys are the only ones the internet with this usage: Google Search: "wart bug tracking"

That's surprising, because I had the vague sense that I'd heard other folks use it in the same way that we are; otherwise I'm not sure why I would have defaulted to using it. I still think it fits: it's something that stands out as being ugly.

Not sure what other word would be simple and still imply "highest priority" or "keep an eye out for solutions for this currently unsolvable and shitty problem". Open to suggestions :) we're switching to Github Issues which is as good a time as any to change terminology. (Though this is the first time I remember somebody thinking Wart was a downgrade instead of an upgrade, FWIW.)

---

on 2011-08-17 at 12:34pm EDT