Skip to content
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

TypeError: Cannot read property 'start' on exec #7

Open
Savageman opened this issue Mar 11, 2016 · 10 comments
Open

TypeError: Cannot read property 'start' on exec #7

Savageman opened this issue Mar 11, 2016 · 10 comments

Comments

@Savageman
Copy link

Hello,

I tried using it but I kept getting "Connection to my_container closed by remote host."

I looked up the log of docker-ssh and this is what I have:

[2016-03-11T10:01:42.522Z]  INFO: sshServer/29 on 1f88d6fb3bdf: Client connected (clientIp=172.17.0.10)
[2016-03-11T10:01:42.615Z] ERROR: noAuthHandler/29 on 1f88d6fb3bdf: NoAuthentication handler is handling the authentication! This is INSECURE!
[2016-03-11T10:01:42.696Z]  INFO: sessionHandler/29 on 1f88d6fb3bdf: Exec (container=my_container , command=my_command")
/src/src/session-handler-factory.coffee:77
                return exec.start({
                           ^
TypeError: Cannot read property 'start' of null
  at Object.callback (/src/src/session-handler-factory.coffee:41:15)
  at /src/node_modules/dockerode/lib/container.js:256:26
  at [object Object].Modem.buildPayload (/src/node_modules/dockerode/node_modules/docker-modem/lib/modem.js:225:19)
  at ClientRequest.<anonymous> (/src/node_modules/dockerode/node_modules/docker-modem/lib/modem.js:210:10)
  at emitOne (events.js:77:13)
  at ClientRequest.emit (events.js:169:7)
  at Socket.socketErrorListener (_http_client.js:259:9)
  at emitOne (events.js:77:13)
  at Socket.emit (events.js:169:7)
  at emitErrorNT (net.js:1257:8)
  at doNTCallback2 (node.js:441:9)
  at process._tickCallback (node.js:355:17)
error: Forever detected script exited with code: 1
error: Script restart attempt #1
[2016-03-11T10:01:44.096Z]  INFO: webserver/34 on 1f88d6fb3bdf: Listening (host=::, port=8022)

I can try things if you tell me :)

@jeroenpeeters
Copy link
Owner

The error isn't really descriptive and I should probably improve on this. In this case the container that you've specified doesn't exist.

Docker-ssh provides ssh for another already existing container. Which container this is is configurable by the CONTAINER environment option. It looks like you've specified 'my-container' but a container with that name doesn't exist.

First figure out which containers are running with docker ps.

@Savageman
Copy link
Author

The container exists and is running. I tried changing the CONTAINER env to another existing one and it also failed. I tried setting CONTAINER_SHELL=/bin/bash too.

But I think I found why: I'm running Docker on Windows, and connection the docker daemon is not accessible at /var/run/docker.sock (the volume) but with tcp on port 2376.

[edit] Hum. Nevermind, I tried installing docker into a container, and running it with the /var/run/docker.sock volume I can do docker stuff (not just docker version, but also docker ps etc.). I'm on Windows, but with the Docker Toolbox, Kitematic and the whole package. In the end it's just a virtualbox VM running boot2docker, so this socket should not be a problem.

Back to beginning.

@jeroenpeeters
Copy link
Owner

Are you sure that when you install docker in a container you're not running the docker daemon in the container as well (docker in docker)? Maybe the docker socket isn't at /var/run/docker.sock in boot2docker.
Anyway, I'm on linux and I cannot support this approach working exactly the same on Windows. If you do get it to work, please let me know so I can update the readme if necessary.

@SacredSkull
Copy link

I also have this problem on Windows and agree that it shouldn't be a problem because the boot2docker VM provides the socket, and is at /var/run/docker.sock (you can check this with docker-machine ssh and locating it). Using the same docker-compose.yml works on Linux, but not Windows despite the container names being the same/existing/etc.. Definitely something to do with the OS.

I wonder if it affects OS X?

@SacredSkull
Copy link

I just wrote a quick dockerfile

FROM jeroenpeeters/docker-ssh

RUN apk --update add curl=7.47.0-r0

For some reason, I had to force that curl version, as otherwise it installed 7.38 which doesn't have sockets support. I was able to successfully run commands like curl --unix-socket /var/run/docker.sock http:/info or http:/images/json but crucially http:/containers/json returns a 404 not found!

I tested the same commands on a Linux box and http:/containers/json worked successfully. Not sure what to make of that.

Note: The single forward slashes are necessary for curl socket requests as far as I know

@Savageman
Copy link
Author

@SacredSkull Thanks for all the testing, really appreciated.

I did some online search, and one scenario which could trigger a 404 could be a version mismatch between the Docker server and the docker client (it was changed and now returns 400 since Docker 1.7 (API version 1.19).

Here's the page: https://docs.docker.com/engine/reference/api/docker_remote_api/

There's an http:/version end-point which displays the API version. Maybe forcing the API version in the URL would help? e.g. http:/v1.xx/containers/json

@SacredSkull
Copy link

The /version request returned 1.22, and using http:/v1.22/containers/json returns a proper json response.

I can't explain it, now the standard http:/containers/json works - but still the script crashes.

@rgabo
Copy link
Contributor

rgabo commented Jul 13, 2016

Ran into the same problem. Unfortunately the code does not check err at https://github.com/jeroenpeeters/docker-ssh/blob/master/src/session-handler-factory.coffee#L68 and just assumes that the call to exec was successful. _container is not null so the container was in fact found, but for some reason _container.exec bails out.

I'll see if I can figure out what's going on.

@rgabo
Copy link
Contributor

rgabo commented Jul 13, 2016

The unexpected happened, doing nothing but adding error handling and rebuilding the image (available as sspinc/docker-ssh:handle-errors in Docker Hub) made the problem go away. Running jeroenpeeters/docker-ssh:1.2.2 errors out.

Given that Node is being used, I would make large bets on an npm package transient dependency issue. The npm install as part of the rebuild made the issue go away. Node <3s you.

@jeroenpeeters let me know if you're open to a PR that adds some extra error handling and I'll open it upstream as well.

@jeroenpeeters
Copy link
Owner

@rgabo, please send me the PR. I would be more than happy to integrate it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants