Invoke version 0.12.2, Ubuntu Wily (15.10 I believe) 64 bits.
The method used:
run("vagrant ssh -- -X -t 'cd /vagrant/; /bin/bash'")
The command run: inv enter
The command itself runs normally and does what is expected of it. When used through invoke it just hangs (no output). Other invoke'd commands work fine.
If you need more info just point me to where it is.
Actually it just hangs whenever it ssh's into a VM. I'm guessing it can't be used to do that then?
I have a similar issue when setting up ssh tunnels:
jumphost = "jumphost"
run("ssh -fN -L localhost:local_port1:remotehost:remote_port1 %s" % jumphost)
run("ssh -fN -L localhost:local_port2:remotehost:remote_port2 %s" % jumphost)
run("ssh -fN -L localhost:local_port3:remotehost:remote_port3 %s" % jumphost)
When running this task it will just hang on the first run command.
Fixed by adding pty=True at the end of the run function.
run("vagrant ssh -- -Xt 'cd /vagrant/; /bin/bash'", pty=True)
Thanks for reporting this - yes, forcing use of a pty often helps with otherwise bizarre issues, some applications misbehave without one.
I'm still curious why this is happening though, no obvious cause is springing to mind (most of them would usually involve either an error or an exit, not a hang). Going to reopen in hopes I have time to investigate sometime; it's possible it's highlighting a bug on our end.
In this case, even with pty=True there were a few errors (the prompt was limited to 100~ characters, after that it glitched - the line turned invisible and deleted the previous line) which I fixed by replacing run() with os.system()
os.system("vagrant ssh -- -Yt 'cd /vagrant/; /bin/bash'")
Sure, that's because run does a lot of stuff os.system does not & cannot do (print+capture, prompt response, etc). Unfortunately it means there are occasionally still frustrating quirks.
If you have time can you paste in some concrete examples of what your terminal looks like in these situations? E.g. what your $PS1 or similar is, etc.
For funsies I poked a bit on my end (I too have a nontrivial prompt setup - it's zsh and prints your usual path, username, git status, etc etc all one one line, then newline + chevron for actual 'prompt'). You can ignore a lot of this as it's mostly rambling to myself, but here's the notes:
Pseudo-terminal will not be allocated because stdin is not a terminal.
Going to leave this open as its own ticket for now but strongly suspect resolving the remaining issues in those tickets mentioned above, will help clear most of this up.
Maybe this helps. I'm seeing both my shell get mangled (bash only, not on zsh) and my run commands (even "ls") fail to return (Ubuntu 14/15/? + Python3). I tried with and without context with no luck, with pty=False I get:
File "/home/agrajag/.virtualenvs/boat/lib/python3.6/site-packages/invoke/runners.py", line 813, in start
File "/usr/local/lib/python3.6/subprocess.py", line 957, in init
File "/usr/local/lib/python3.6/subprocess.py", line 1484, in _execute_child
self.pid = _posixsubprocess.fork_exec(
AttributeError: 'NoneType' object has no attribute 'fork_exec'
My problem was that my tasks were along side my app and my app used gevent. Grabbing a constant from the app was causing gevent to monkey patch subrocess and _posixsubprocess.fork_exec didn't like that. My solution was to not import from my app in a way that caused gevent to monkey patch subprocess (in my case by moving the constant to utils, a non-gevent module that can be shared with tasks.py). Gevent being installed in the venv was not enough to trigger it, just monkey patching all.
Perhaps this issue could be addressed by detecting if gevent has been monkeying around and warn the user about potential issues. Happy to provide more feedback/debugging if you need it.
Back to this after doing #350. Interestingly, I can't even recreate this anymore on master, let alone the branch for #350. Possible some of the other work in the interim fixed it. (There was definitely a "make encoding errors explode always instead of hanging" fix I put in a few days ago on master, which is definitely related to this, but that doesn't explain why the actual encoding error we talked about above, didn't show up for me...)
But yea - I can do run("ssh -t myvm /bin/zsh", pty=True), get my dotfiles w/ funky prompt, and the shell works fine, no exceptions, no hang. True both on master and on my encoding branch. If you're happy grabbing from git and testing, be my guest, otherwise this work will be released as 0.13 in the near future. Closing this for now, please comment if you can still recreate hangs.
run("ssh -t myvm /bin/zsh", pty=True)
Note - pty=False still has the issues mentioned above, but that's a completely separate issue as far as I can tell, related to running a shell interactively while it is not in interactive mode (because there's no pty in play). There may never be anything we can do there besides make sure "use pty=True for interactive things!" is as loud as possible in the docs.