-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
drush fails to receive output from non interactive ssh commands in some circumstances #2805
Comments
While debugging I also found that adding a pause before closing the process causes
|
I believe that the deadlock only happens on Windows systems. We might potentially be able to just conditionally only close this pipe on Windows boxes. Not sure if that might cause problems if the local system was non-Windows connecting to Azure or something. |
Please confirm if this is still an issue on the HEAD of master. Drush is now using the Symfony Process component rather than backend invoke. Should work better. |
Sorry, we stopped ssh'ing into Docker containers so I don't have an environment to test this anymore. |
Hi,
I'm using docker and the following docker image to provide an SSH container https://hub.docker.com/r/jeroenpeeters/docker-ssh/
I want to access a docker based Drupal site using drush and drush aliases. Everything works apart from drush commands that execute SSH commands non interactively. An example being user-login e.g.
drush @docker uli
Degbugging shows the SSH command is executed but drush running outside of the container receives no output from the command. If I manually run the SSH command drush creates, it works fine so its just that the output is not ending up at the local version of drush running outside the container.
On further investigation I found that in backend.inc, the process pipe gets deliberately closed. If I comment this fclose out then the command works as expected.
The line is in
_drush_backend_proc_open()
. In drush 8.1.12 its line 389. I've copied it below along with the comment that goes above it:-Clearly this works in most environments, I was wondering what might be special with my setup that requires the removal of this line? What is it even there for? I couldn't work it out from the comment!
If others happen across this issue then maybe an optional toggle can be added to an alias to prevent this?
The text was updated successfully, but these errors were encountered: