Cannot attach debugger to a node.js application running inside a Docker container

[weinand]

From @m90 on November 18, 2015 16:44

I'm trying to attach the Visual Studio Code debugger to a node.js app that is running inside a Docker container.

The app starts like:

node --debug-brk app.js

My docker-compose.yml exposes the port for attaching:

app:
  build: .
  working_dir: /code
  volumes:
    - .:/code
  command: npm run debug
  ports:
    - "3004:3000"
    - "5858:5858"

launch.json is pretty simple:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Docker",
            "type": "node",
            "request": "attach",
            "port": 5858
        }
    ]
}

Now, when I start the application and attach the debugger this will correctly connect (I can see the values flashing in the debugger UI already), but then it will stop, telling me the following:

Error opening 'app.js' (File not found: /code/app.js).

Is there any way to fix this path offset? Should one handle this scenario completely different?

Copied from original issue: microsoft/vscode#59

[weinand]

VS Code assumes that the (absolute) file paths returned from node.js, can be found in the filesystem where VS Code runs. As long as node.js runs on the same system as VS Code, this is always the case.
In your case node.js runs on a different system than VS Code, so the paths returned from node.js are not valid in VS Code.

We are planning to improve this path mapping soon. Until that has happened, can you try tweak your setup, so that the docker paths are valid paths on your host system too? (e.g. by using symbolic links).

[weinand]

From @m90 on November 19, 2015 15:27

Thanks for getting back to me so fast. I already tried the symlinking approach and everything mentioned in this Stack Overflow post (notice that although the question is 0.8, the issues persist) but could not get it to work in any constellation.

Should symlinking work in theory (i.e. has anyone of you ever managed to debug a node app inside a container yet)?

[anibali]

@m90 I tried the symlinking approach with no luck. After a few seconds the debugging session just closes.

[silverbp]

I'm trying to accomplish the same thing.

Where did you get this error from? Error opening 'app.js' (File not found: /code/app.js).

Also I assume since you didn't document any steps on forwarding ports that you are running this on linux? Also, how did you get around node not exposing 5858 outside the machine?

We are running on OS X and with our current setup, we can volume map in the path exactly as it is on our system. We also had to use balance to forward 5858 to 5958 out of the container. We have been able to use Webstorm and node debug command line to get to 5958 for quite some time. The whole volume mapping to the same exact path inside the container just occured to me last night. However the debugger attaches and then shuts down after a few seconds with no error.

I also had to port forward the debug port out of boot2docker/virtualbox because vscode got rid of the address with attaching to a node process. I used to be able to successfully attach to a process but couldn't add or hit any break points due to the mismatch on paths.

[silverbp]

So I have 5858 forwarding out to 5958 and 5958 exposed to boot2docker/virtualbox as 5958 and then I virtualbox forwarding that to 55958 on OS X. I can connect to 55958 on localhost using node debug cli so I know it works. Also the paths are exactly the same inside the container as they are on my drive. It attaches for about 3 seconds and then fails with no error.

[m90]

Also I assume since you didn't document any steps on forwarding ports

The port forwarding is declared in the docker-compose.yml up above.

[silverbp]

Sorry, let me clarify. In my experience you can not map/forward 5858 outside the container because it's bound to the local interface and isn't accessible from outside the running host. So we had to use balance to forward 5858 to 5958 inside the container. So our docker compose file would look like this:

5958:5958 (or you could even map it back out to 5858 on the host)

maybe node has fixed this since I last set this up. (We originally set this up on node 0.10 and are now running 5.0 in some circumstances) I just haven't revisited it.

[silverbp]

@anibali my session closes after a few seconds as well although I'm not using symbolic links, I am mapping the folder in to the same exact path as what is running on OS X and my session just closes after a few seconds as well! I wonder if there's some log or a way of getting the error or what is happening.

[silverbp]

Also to clarify on older versions of VSCode, i was able to attach to the debugger by just specifying a remote address and port. I just couldn't set breakpoints. Now i can't attach to the debugger anymore, if I could, I think the path resolution I came up with would actually work!

[silverbp]

@m90 just verified balance is no longer necessary, well that's good to know!

[silverbp]

I do get the following error in the docker console output from node when vscode just disconnects after 2 to 3 seconds (well sometimes I get the error)

events.js:141
       throw er; // Unhandled 'error' event
      ^

 Error: This socket has been ended by the other party
     at Socket.writeAfterFIN [as write] (net.js:268:12)
     at Client.send (_debug_agent.js:168:15)
    at _debug_agent.js:55:14
    at Array.forEach (native)
    at DebugAPI.Agent.binding.onmessage (_debug_agent.js:54:18)

[silverbp]

So close!

I have a feeling this would actually work in an older version of VSCode as it would at least attach and stay attached.

https://youtu.be/tTo0xTChbW4

I've attached a screencast, if you volume map the code in so the directories are exactly the same and tell it to break on start, you can see it breaking in the right place when it initially starts!. But then it detaches at the 2-3 seconds. Like I said it used to stay attached on older versions at least, it's actually gotten worse as far as trying to debug in a docker container.

[silverbp]

instead of using symbolic links try this:

app:
  build: .
  working_dir: {whatever './' resolves to.. full path}
  volumes:
    - ./:{whatever './' resolves to.. full path}
  command: npm run debug
  ports:
    - "3004:3000"
    - "5858:5858"

[silverbp]

unless the local directory structure you've chosen conflicts with something in the container, you should be fine.

[silverbp]

I checked all the way back to 0.7.0, but it requires mono before 0.7.0 and I know I ran it before with mono, that's probably where I got it to attach, you can also specify an address in 0.7.0 to connect to. You can't do this in newer versions anymore. Are there any logs anywhere that would tell me why it's just disconnecting?

[m90]

I'm still having the same issues, even when using the approach above (I'm running Ubuntu 14.04 in case that matters):

app:
  build: .
  working_dir: /home/m90/project
  volumes:
    - ./:/home/m90/project
  command: npm run debug
  ports:
    - "3004:3000"
    - "5858:5858"

[silverbp]

Are you seeing a different error or the same one that the path can't be found? My issue is it just drops the session with no error after a few seconds. @weinand, is there a place where there are logs at where I might be able to get more information as to what's happening?

[silverbp]

@m90 does the container run as root user or a different user? What does your dockerfile look like that you are building?

[m90]

I'm not seeing any error message anymore, the debugger just detaches. I can even inspect things for a while (yet everything is undefined).

Dockerfile is pretty simple:

# Inherit from Heroku's stack
FROM heroku/cedar:14

# Internally, we arbitrarily use port 3000
ENV PORT 3000
# Which version of node?
ENV NODE_ENGINE 4.2.1
# Locate our binaries
ENV PATH /app/heroku/node/bin/:/app/user/node_modules/.bin:$PATH

# Create some needed directories
RUN mkdir -p /app/heroku/node /app/.profile.d
WORKDIR /app/user

# Install node
RUN curl -s https://s3pository.heroku.com/node/v$NODE_ENGINE/node-v$NODE_ENGINE-linux-x64.tar.gz | tar --strip-components=1 -xz -C /app/heroku/node

# Export the node path in .profile.d
RUN echo "export PATH=\"/app/heroku/node/bin:/app/user/node_modules/.bin:\$PATH\"" > /app/.profile.d/nodejs.sh

ONBUILD ADD package.json /app/user/
ONBUILD RUN /app/heroku/node/bin/npm install
ONBUILD ADD . /app/user/

[silverbp]

Yeah, I think your path problem is solved, now you have the same issue I do! I can even get it to break out on start if you do debug-brk (in the right spot) , but it disconnects after 2 to 3 seconds.

[m90]

Yes, same behvaior around here.

[silverbp]

and node cli debugger has always worked for us, so it's not a connection issue...

[djabraham]

I just noticed that you had the same problem I did! It's good to know that I am not the only one.

I really like this little editor, even more than Sublime, so I went through the pain and managed to figure out why it was terminating, and also managed to create a little workaround, if you are interested.

#29

[weinand]

Attaching a debugger to a node.js application running inside a Docker container will work in the January drop of VS Code.

[djabraham]

This is awesome. Thanks for this feature, and for the quick fix!

[saborrie]

How did you guys get past the port forwarding problem?

[djabraham]

Are you using docker-machine? If so, you have to setup NAT using virtbox..

#29 (comment)

You can use the same ma home port, if you want, so 5858:5858 should work.

[saborrie]

Thanks for the reply, but my problem turned out to be because I was using Node 7.x, so I had to add the 0.0.0.0 into the debug argument when calling node: e.g. node --debug=0.0.0.0:5858 app.js

[djabraham]

That's a good find. I'm actually using Docker native for OSX now, and have seen a couple of similar issues. Perhaps the native containers don't bind to 127.0.0.1, and the ambiguity of 0.0.0.0 helps it to connect?

So for others having similar issues, I think your fix may extend beyond node 7.x updates.