dep hangs when subcommands try to read from stdin

Created on 22 Dec 2017  ยท  9Comments  ยท  Source: golang/dep

What version of dep are you using (dep version)?

v0.3.2-163-g5d5088d6

What dep command did you run?

I ran dep init -gopath -v while in a directory only containing the file _main.go_ below.

// main.go
package main

import (
    "fmt"

    . "github.com/test/color"
)

func main() {
    fmt.Println("vim-go")
}

My intention was to add a repo from my own gopath under src/github.com/test/color (for testing purposes). I deleted the .git information in this directory.

What did you expect to see?

I expected this to work: because of the _-gopath_ flag it would just go and get the repo info from the gopath.
If for some reason it didn't do this and tried to get the information from github, I would have expected it to fail.

What did you see instead?

โฏ dep init -gopath -v
Getting direct dependencies...
Checked 1 directories for packages.
Found 1 direct dependencies.
Searching GOPATH for projects...

This text came up. I waited a long time for it to do something (10-20 mins) and it was just stuck here.

Most helpful comment

I hit this with my encrypted id_rsa (needs password). I think it's pretty poor form require an ssh-agent to be running rather than decrypting it when needed, personally... At the very least it could print some sort of info (or fall back to serial network connections, or both), or work with CTRL-C (it doesn't currently, because it waits for the git process to end).

Right now it just silently fails.

If, as above, GIT_SSH_COMMAND is used, git 2.3 or higher will be required to function properly, but at least dep could fail gracefully or work serially.

All 9 comments

So seeing this, I did some investigation as to why it just froze like this. The freeze occurs in gps/cmd_unix.go. Here is what I found:

  • The one repo that it tries to pull in doesn't exist.
  • It first tries https. That doesn't work because it doesn't exist so it goes onto the next option: ssh.
  • It tries to make the connection with ssh and this is where it freezes. (The git ls-remote command witht he ssh address)

I tried running the git ls-remote ssh://[email protected]/test/color command on my terminal and it showed the known_hosts prompt:

The authenticity of host 'github.com (192.30.253.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)?

So I assumed that the freeze up occurs because git ls-remote ssh... can't proceed witht he action because github is not a 'known_host'.

On my own run of git ls-remote ssh://[email protected]/test/color I said yes to the prompt (thus adding github in .ssh/known_host. Then, whenever I tried to repeat this bug and freeze it up, it gave the error as it should have. Deleting github from the known_host file made the freezing resume.

Possible Solution

In trying to find a solution for this I stumbled across the "GIT_SSH_COMMAND" environment variable. Just like the "GIT_ASKPASS=", "GIT_TERMINAL_PROMPT=0" variables are set, if the
GIT_SSH_COMMAND='ssh -oBatchMode=yes' variable is set, this makes ssh not display the _The authenticity of host_ message, thus not hanging up the progam. When I tried this, it would fail as expected and not hang. So maybe we would want to add the GIT_SSH_COMMAND='ssh -oBatchMode=yes' environment variable as well.

hmm, interesting. I don't think we can do that safely, though, as we do need to support the case - at least eventually, we clearly don't now - where passworded login works. see Masterminds/glide#411, which is that, but also a step further.

I think I am also able to reproduce this issue. My dep init stuck for a long time.

is it possible to sniff the state of running subprocesses to see if they're blocked reading from stdin? we might be able to use that to make a smart decision here.

I hit this with my encrypted id_rsa (needs password). I think it's pretty poor form require an ssh-agent to be running rather than decrypting it when needed, personally... At the very least it could print some sort of info (or fall back to serial network connections, or both), or work with CTRL-C (it doesn't currently, because it waits for the git process to end).

Right now it just silently fails.

If, as above, GIT_SSH_COMMAND is used, git 2.3 or higher will be required to function properly, but at least dep could fail gracefully or work serially.

By the way setting env variables in the current codebase to disable prompting doesn't work as expected.
https://github.com/golang/dep/blob/b2afe44d132da37a16a84aca7d84ddb0d9802020/gps/vcs_source.go#L265

If GIT_TERMINAL_PROMPT is previously set to a positive value, say in .bashrc it'll just ask for password and hang.

And the reason of the hang is that Setpgid is used, child processes that read from the terminal get SIGTTIN'ed, see man 2 setpgid.

Just for anyone who encounters this the current workaround is to use ssh-agent to open your key up for dep. For example (use at your own risk):

eval `ssh-agent`
ssh-add PATH-TO-SSH key
dep ensure -v

More unfortunate is that dep just hangs if it can't ssh [email protected] git-upload-pack '/Organization/Project'. No error message, no exit.

/cc

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikkeloscar picture mikkeloscar  ยท  45Comments

godcong picture godcong  ยท  27Comments

calmh picture calmh  ยท  39Comments

avelino picture avelino  ยท  25Comments

davecheney picture davecheney  ยท  32Comments