New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange input handling on Windows in Fab2 #1875
Comments
Thanks for the report. I'm unable to perform diagnosis on Windows systems myself but hopefully somebody else may be able to reproduce. I can say we've definitely squashed a number of terminal & encoding related issues related to Windows in the past so things should be pretty stable there, but you may have found another one. Another question triggered by another ticket - has this always happened or did it only start recently? Another user reported some weird behavior (but different than this reported symptom) after a recent Windows update. |
I can't say, whether it started recently or not, because I have not tested it before.
|
Hi, Any fix on it. We have the same issue as above shown. 2019-08-07 11:31:30,590 - vm-1.0-GA-x86_64-minimal-template-1.0-Update-917-1565202528 - INFO - exec [cd /root || exit $?; mkdir -m 777 -p /mnt/shared-1565202528] Thread args: {'kwargs': {'echo': None, Traceback (most recent call last): File "/root/workspace/upgrade-test-CI-in-harness/update-basic-in-harness/.venv/lib/python3.6/site-packages/invoke/util.py", line 233, in run File "/usr/lib/python3.6/threading.py", line 864, in run File "/root/workspace/upgrade-test-CI-in-harness/update-basic-in-harness/.venv/lib/python3.6/site-packages/invoke/runners.py", line 706, in handle_stdin File "/root/workspace/upgrade-test-CI-in-harness/update-basic-in-harness/.venv/lib/python3.6/site-packages/invoke/runners.py", line 939, in close_proc_stdin NotImplementedError |
Same problem occurred at 2019/08/07 def ssh_login_target_nas():
""" Use ssh to login the target NAS
return
type: <class 'fabric.connection.Connection'>
"""
# Set up fabric's login information
host = SSH_ACCOUNT + "@" + SELF_NAS_IP_ADDRESS
# Connect to your nas
c = Connection(host = host, connect_kwargs={"password": SSH_ACCOUNT_PASSWORD})
try:
hostname = c.run('hostname').stdout.strip()
logger.debug("Connect to NAS: " + hostname)
except Exception, error:
logger.error(error)
raise SystemExit
return c I could get hostname from stdout. But I still got the exception like below.
My content of requirements.txt like below:
I found that I would install different version of packages after executing 2019/08/06. It could execute properly
2019/08/07. Failed
The version of invoke package is different. |
Here is a breaking change of invoke from 1.2 to 1.3 verion. |
great find @baconYao, this was blocking me as well. downgrading invoke for now to 1.2 has gotten me past this issue. Much appreciated. |
Same here, on any key press in continuously running threaded task, I get socket error.
|
I had the same problem with 2.4.0. I was using fab inside a celery task. For some reason upgrading to 2.5.0 solved it. |
This issue could also be connected to Windows or WSL environments. We had the same stacktrace using latest Ubuntu WSL on latest Windows 10, and solved it by running our tasks on macOS. The strange thing is, that most tasks also worked on WSL, only a very long task (many run() commands) did fail with this exception non-deterministically, i.e., after some uncertain number of commands run. |
I am so glad I was able to find this. |
On further investigation, it could also be connected to the Responder class. We used a responder to answer "yes" on a couple of quick consecutive .run() commands, and this would fail on WSL. Removing the Responder objects and calling "yes | the-command" instead worked on WSL as well. |
Fabric 1 handles manual input correctly, but Fabric 2 behaves strangely, with pty or without.
Tested on Windows 7 64b in cmd, Python 3.7 64b, with Fabric versions:
Fabric3 1.14.post1, Fabric 2.3.1, Paramiko 2.4.1, Invoke 1.1.1
The text was updated successfully, but these errors were encountered: