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

Chrome DevTools not able to connect to Node inspect since 7.5.0 #11591

Closed
owenallenaz opened this issue Feb 27, 2017 · 31 comments

Comments

@owenallenaz
Copy link

commented Feb 27, 2017

  • Version: 7.5.0, 7.6.0
  • Platform: Linux nodeServer 2.6.32-573.el6.x86_64 #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux (VM) on Windows 10
  • Subsystem: Debugger

When I run a script with --inspect, I am no longer able to connect via Chrome DevTools since Node 7.5.0. When I attempt to connect I get "Debugging connection was closed. Reason: WebSocket disconnected Reconnect when ready by reopening DevTools" Clicking reconnect DevTools does not reconnect."

Simple script:

> node --inspect=8080 -e "setTimeout(function() { console.log('yes'); }, 30000)"
Debugger listening on port 8080.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:8080/e7cadd27-e1d6-42d3-8c53-c407dd543ec5

If I perform those steps on Node 7.4.0, it works. If I do the same steps in Node 7.5.0 or 7.6.0, the URL will no longer connect. I have the same results if I utilize Chrome 56.0.2924.87 or Canary 58.0.3025.0 on Windows.

I've recorded a screencast showing the steps to recreate and it functioning on 7.4.0 and failing on 7.6.0: https://www.screencast.com/t/vFyha8YI5

@mscdex mscdex added the inspector label Feb 27, 2017
@mscdex

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2017

@brantw

This comment has been minimized.

Copy link

commented Feb 28, 2017

I've also seen this. Debugging seems to work locally but not remotely. This also affects --debug as well as --inspect. For example, in node 7.6.0 I can node debug on the host running node, but cannot node debug server_name:5858 from another host. If I downgrade to 7.4.0 I am able to connect to the debugger remotely.

@bnoordhuis

This comment has been minimized.

Copy link
Member

commented Feb 28, 2017

I suspect #9691 is responsible. It harmonizes option parsing with the old debugger but it presumably changed the default from 0.0.0.0 to 127.0.0.1 (although I'm 80% sure that was the default for --debug already.)

I'd say it's a good thing, security-wise. You can opt-out with --debug=0.0.0.0:5858 or --inspect=0.0.0.0:9229.

@sam-github

This comment has been minimized.

Copy link
Member

commented Feb 28, 2017

Sounds like the debug port is bound to localhost by default now, since opening it to remote connections allows remote attackers unfettered access, but I don't see signs of this in the changelog.

But there should be a way to change the default if its explicitly wanted.

@ofrobots, do you know anything about this?

@eugeneo

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2017

@sam-github
As @bnoordhuis pointed out, you can specify an IP address to listen on. Inspector is still an "experimental feature" so I did not think that this bugfix needed to be reflected in a change list...

@sam-github

This comment has been minimized.

Copy link
Member

commented Feb 28, 2017

My comments and Ben's crossed on the wire.

It was an unexpected change in how node behaves, it should have been documented. Experimental doesn't mean "we don't tell you when we changed it, post a github issue if you'd like to know more". I don't think it means "we reserve the right to make breaking changes in minor updates" either. cc: @Trott

I think the change to default to localhost is a good one, but I'm not sure it should have happened before 8.x (though security fixes are allowed to majors even when breaking, the CTC has the power to give them special exemptions).

Btw, something is wrong here: https://github.com/nodejs/node/pull/9691/files shows zero changes in the diff, and no commits, but also says its merged. I haven't seen that before in github, it sure makes it hard to review the PR retroactively to see what was merged.

@eugeneo any idea what is going on with the PR?

@eugeneo

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2017

I am not sure what had happened to the pull request display - the actual commit can be seen here - f9aadfb

But it looks like the change is really this one - #10878

@brantw

This comment has been minimized.

Copy link

commented Feb 28, 2017

I can confirm --debug=0.0.0.0:5858 does allow for remote debugging again in 7.6.0. I see why the change is beneficial from a security standpoint, but I wish there had been some docs for this change. It would have saved several cycles trying to track down why remote debugging stopped working.

@sam-github

This comment has been minimized.

Copy link
Member

commented Feb 28, 2017

@eugeneo can you PR some docs for the current state, something saying what address is listened on by default?

@owenallenaz

This comment has been minimized.

Copy link
Author

commented Mar 1, 2017

While the --debug pathway might work, I'm not sure if there is a way to get the --inspect pathway as it stands on 7.60. I've tested a couple different variants. Looking at the code in the commit, it was altered to use host pretty much everywhere, but if you look at the original code, sometimes it was 0.0.0.0 and othertimes it was 127.0.0.1. Well with the host var it's using the same value everywhere, even though previously it was 2 distinct values. In example the URL that was spit out always contained 127.0.0.1 but then the there was the line for uv_ip4_addr("0.0.0.0", port_, &addr); which had 0.0.0.0 hardcoded.

I've tried variants of passing --inspect=0.0.0.0:8080 and using the URL given back as well as altering the url to contain 127.0.0.1:8080. I've also tried the opposite where I pass --inspect=127.0.0.1:8080 and use the URL or switch the url to be 0.0.0.0:8080. None of the attempts work. Some of them will "connect" but it's a weird state where I'm not able to actually get to any of the sources files, or interact with anything, but it's not giving me the disconnection error.

If someone has figured out a proper set of steps to use --inspect or --debug but connect via Chrome, I'm happy to use it as a work-around. For now we've just reverted back to 7.4.0 in the meantime.

@eugeneo eugeneo self-assigned this Mar 1, 2017
@eugeneo

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2017

I don't think remote debugging was tested enough. I am assigning this over to me - I see issues like json/list returning 0.0.0.0 as a host name (should be detected), I also expect other similar problems.

@oldrich-s

This comment has been minimized.

Copy link

commented Mar 5, 2017

I also experience issues with --inspect since version v7.5.0. When I install v7.4.0 the inspector works just fine. As soon as I install v7.5.0 or higher the inspector ends with empty sources, i.e. no files are present. Sometimes if I wait long enough the files in sources appear. Still I am not able to set any breakpoint in the files. To me something went really bad between version 7.4.0 and 7.5.0...

@sam-github

This comment has been minimized.

Copy link
Member

commented Mar 6, 2017

It sounds like an unintended semver-major occurred between 7.4 .and 7.5, should it be reverted? @nodejs/ctc

Change was:

  • default listen address for --inspect changed to localhost

Which is particularly problematic because there seems to be a (unrelated?) bug in the inspect option:

  • using unspecified/INADDR_ANY listen address does not work
@eugeneo

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2017

@czb what you are seeing sounds like #11589 - fix was merged in last Friday.

@eugeneo eugeneo referenced this issue Mar 8, 2017
2 of 2 tasks complete
@eugeneo

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2017

I performed some tests and the only issues I've seen had been caused by the code returning wrong IP addresses in the JSON responses - that was just fixed.

I believe this can be closed now.

@myuseringithub

This comment has been minimized.

Copy link

commented Mar 16, 2017

Hi there, fixed. It works with latest versions 7.5+.
Had to change to a specific IP, rather than using 0.0.0.0 as NIM automatically would use it, instead of a fixed IP.

jungx098 added a commit to jungx098/node that referenced this issue Mar 21, 2017
JSON target list response will now return appropriate IP address
for instances listening on 0.0.0.0.

Refs: nodejs#11591
PR-URL: nodejs#11755
Reviewed-By: James Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
@joshgav joshgav referenced this issue Apr 19, 2017
4 of 4 tasks complete
@jpike88

This comment has been minimized.

Copy link

commented May 19, 2017

This is still a rather annoying change. It would have been nice to just another parameter like --inspect-insecure or something... there's already a hash in the URL to protect against hijacking.

@nsisodiya

This comment has been minimized.

Copy link

commented May 23, 2017

I was using node app inside docker. I was unable to dubug it in Chrome dev tools. Later I found that, I have to change syntax.

FROM

nodemon --inspect ./src/server.js --exec babel-node -e js

TO

nodemon --inspect=0.0.0.0:9229 ./src/server.js --exec babel-node -e js

Now debug is working.

@kenny-reyes

This comment has been minimized.

Copy link

commented Jun 2, 2017

This works for me @nsisodiya.

Thanks

@AlexanderAllen

This comment has been minimized.

Copy link

commented Jun 9, 2017

Took a while to get this working.
Confirmed that @nsisodiya solution works.

Docker Compose

  node:
    image: node:8.0-alpine
    volumes:
      - ./apps:/opt/apps
    ports:
      - 9229:9229
    expose:
      - 9229

Make sure to publish ports, otherwise connection refused:
docker-compose run --rm --service-ports node bash

Verified using "localhost" instead of 0.0.0.0, but --inspect-brk=0.0.0.0:9229 works as well!

bash-4.3# node --inspect-brk=localhost:9229 index.js
Debugger listening on ws://localhost:9229/33dc4d2a-7a17-47ac-bf64-f66329d60872
For help see https://nodejs.org/en/docs/inspector
Debugger attached.

On Chrome:

chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/14b1c01b-e7f4-40e2-8b59-e914b38209d1

I'm using the Node.js V8 --inspector Manager (NiM) Chrome plugin as well to get to the chrome-devtools address.

@sheetaldubey

This comment has been minimized.

Copy link

commented Jul 8, 2017

i have node 7.4.0 and i am using mac. As I am starting node server in debug mode

node --debug server.js

The server starts successfully by giving message as Debugger listening on 127.0.0.1:5858

but my chrome not able to load 127.0.0.1:5858.

Any workaround for this.?

@bnoordhuis

This comment has been minimized.

Copy link
Member

commented Jul 8, 2017

@sheetaldubey --inspect, not --debug. Also, you should probably upgrade to the latest v7.x or v8.x release.

@MohammedEssehemy

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2017

Thanks @nsisodiya

@PopradiArpad

This comment has been minimized.

Copy link

commented Oct 13, 2017

To debug a node.js service in a docker stack from the Chrome DevTools locally you need to configure
the listening port of the debugger with the long syntax and the inspect parameter as @nsisodiya said :

    command: node --inspect=0.0.0.0:9229 some.js
    ports:
      - target: 9229
        published: 9229
        protocol: tcp
        mode: host

That's all...chrome://inspect will be able to detect the listening debugger as usual.
Remarks:

  1. It's possible that the network must be attachable.
  2. Current Chrome has problem with a docker network on localhost. Use 127.0.0.1 instead.
@forabi forabi referenced this issue Nov 4, 2017
2 of 2 tasks complete
@danielo515

This comment has been minimized.

Copy link

commented Nov 15, 2017

How can I activate remote debugging it on an already running process when I activate the debug protocol by using kill -s SIGUSR1 ?

@dechamp

This comment has been minimized.

Copy link

commented Nov 16, 2017

@bnoordhuis Dude, you saved me!!! I spent 3 hours trying to figure out why my inspectors wouldn't work. I knew it had mostly to do with me running via docker. But the bind to 0.0.0.0 solved it!!!! You rock!

@wzup

This comment has been minimized.

Copy link

commented Dec 27, 2017

Can't debug live.
This alert pops up every time I try to save a file. What's that? It's not possible to debug/develop when debugger doesn't reload automatically

dev tools

I use nodemon to reload my node.js server. My config for it:

{
    "restartable": "r",
    "verbose": true,
    "env": {
        "NODE_ENV": "development",
        "DEBUG": "app:*",
        "DEBUG_COLORS": true
    },
    "ignore": ["routes/___*.js", "routes/___*.html"],
    "debug": true,
    "ext": "js dust html css scss rb json htpasswd",
    "exec": "set DEBUG=express-mysql-session* & node --inspect=0.0.0.0:9229 --debug-brk ./bin/www"
}

Chrome 63.0.3239.108 (Official Build) (64-bit)
Node v6.11.5
Windows 10 64x

@JeffML

This comment has been minimized.

Copy link

commented May 11, 2018

Got this working. In package.json:

"scripts": {
		"debug-remote": "babel-node --inspect=0.0.0.0:9229 ./app.js nocluster",

Then run
npm run debug-remote

and on my local box, go to node-inspector:

chrome://inspect/#devices

add (via configure) the remote device:

172.00.00.00:9229 // replace IP with real remote IP address

Save it, and the remote target list should give you a connection link. Click it and you're good to go.

@LauItachi

This comment has been minimized.

Copy link

commented Jul 14, 2018

Oh My Lord @bnoordhuis, I try node --inspect-brk xx.js for 4days' debugging without any work.
Finally !!! node --inspect=0.0.0.0:9229 --inspect-brk xx.js works!!!

@softmantk

This comment has been minimized.

Copy link

commented Jul 22, 2018

I am using puppeteer to launch headless chrome. The problem with me is that I can't use a static port.
The application is being used by multiple users. Each users have to have a chrome browser open to themselves. So I need to expose multiple ports in docker. but it needs to be dynamic.

gshively11 added a commit to gshively11/babel-watch that referenced this issue Nov 28, 2018
- This is required due to a change in node, [see here](nodejs/node#11591).
- Also adds a new -K argument (inspect-brk).
- Updated README and help text to explain new/updated arguments.
@creativesoftwaregun

This comment has been minimized.

Copy link

commented Jan 21, 2019

Current setup is a VM hosted on VMWare using NAT and port 9229 forwarded from VM to host.
NodeJs is v8.10 and Chrome is v71 and the below command works

node --inspect-brk=0.0.0.0:9229 sample_debug.js

thanks to @bnoordhuis @nsisodiya

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.