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

Added inspect port overriding in cluster #13761

Conversation

mutantcornholio
Copy link
Contributor

This is third part that I've mentioned in #9659 (comment)

Current cluster inspect port logic doen't let user to manually set inspect port for workers.
After this commit, adding any --inspect* options to cluster.settings.execArgv will disable port autoincrement.

Fixes #8495 and #12941.

I've got a problem with these cases:

  1. If user starts master with --inspect-port but adds --inspect to cluster.settings.execArgv (set the base port, but don't run master with inspector), autoincrementing logic will be disabled. I can't say if this behavior is good or bad. Probably, port overriding should take place only if --inspect=* or --(inspect|debug)-port= are passed.
  2. This approach doesn't fix the case if master starts on zero port and user wants workers to work on zero port too, instead of listening on ports incremented from some port: cluster.settings.execArgv will already contain everything in process.execArgv and adding --inspect=0 to cluster.settings doesn't change anything. (link: test: fix test-inspector-port-zero-cluster #13373 (comment))

So maybe instead of this, I should just add inspectPort option right to cluster.settings?

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

@mscdex mscdex added cluster Issues and PRs related to the cluster subsystem. inspector Issues and PRs related to the V8 inspector protocol labels Jun 18, 2017
@mutantcornholio
Copy link
Contributor Author

cc/ @refack @Trott @bnoordhuis @cjihrig

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Not even sure It's semver-major IMHO it's a bug fix.

.filter((arg) => arg.match(debugArgRegex))
.sort();

let debugSettingsOverriden = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion:
const debugSettingsOverriden = clusterDebugArgs.any((v, i) => v != masterDebugArgs[i]);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option, make cluster.settings.execArgv a getter/setter property and do check-on-assignment

@refack
Copy link
Contributor

refack commented Jun 19, 2017

If user starts master with --inspect-port but adds --inspect to cluster.settings.execArgv (set the base port, but don't run master with inspector), autoincrementing logic will be disabled. I can't say if this behavior is good or bad. Probably, port overriding should take place only if --inspect=* or --(inspect|debug)-port= are passed.

There is also #13228 and initiating debugger with SIGUSR1. IMHO if there is no simple solution they could be dealt with in a future PR.

This approach doesn't fix the case if master starts on zero port and user wants workers to work on zero port too, instead of listening on ports incremented from some port: cluster.settings.execArgv will already contain everything in process.execArgv and adding --inspect=0 to cluster.settings doesn't change anything. (link: #13373 (comment))

Are you sure? It works from the CLI:[edit] should be overridable with cluster.setupMaster({execArgv: ['--inspect', '--inspect-port=0']});

d:\code\node-cur$ node --inspect=9229 --inspect=0
Debugger listening on ws://127.0.0.1:52153/590e5e9c-6118-475a-94e5-78103994953c
For help see https://nodejs.org/en/docs/inspector

@refack
Copy link
Contributor

refack commented Jun 19, 2017

IMHO since no tests were changes, and this feels more like a bug fix then behaviour change this could be semver-patch

P.S. @mutantcornholio https://github.com/nodejs/node/blob/master/doc/api/cluster.md#clustersetupmastersettings should be updated to reflect it does accept execArgv (and always did 4cd522d). Unless anyone knows of a reason why it was never documented? @AndreasMadsen ? (f9a47de)

@refack refack self-assigned this Jun 19, 2017
@mutantcornholio
Copy link
Contributor Author

I promise to update the docs before it gets merged (see unchecked box in checklist?)
But first, I want to cover the cases I've mentioned — maybe use another approach.

I like the idea of making cluster.settings.execArgv a getter/setter.
Can anyone see a downside there?

@AndreasMadsen
Copy link
Member

Unless anyone knows of a reason why it was never documented? @AndreasMadsen ?

Sorry, I think it is 6 years ago since I wrote that code :p Node.js had poor support for debugging at that time, I think it mostly happened through the terminal gdb interface at that time. So debugging cluster workers was not something we had considered. We just ensured that it would be possible to execute the worker as standalone and debug it that way. Obviously, things have changed since then. I don't use the cluster module these days, so I don't have any opinion, just stories to tell :)

@refack
Copy link
Contributor

refack commented Jun 19, 2017

so I don't have any opinion, just stories to tell :)

👍
BTW: I was using WebStorm 1 in 2010. GUI rulez.

@Trott
Copy link
Member

Trott commented Jun 19, 2017

/cc @mcollina @nodejs/v8-inspector

@mutantcornholio
Copy link
Contributor Author

Wait, cluster.settings.execArgv is an array. And we're already using .push() on it.
Unless we use something like this (which, I hope, we won't), I don't see, how getter/setter would help :(

@refack
Copy link
Contributor

refack commented Jun 20, 2017

Wait, cluster.settings.execArgv is an array. And we're already using .push() on it.
Unless we use something like this (which, I hope, we won't), I don't see, how getter/setter would help :(

hmmm...
Well at least setupMaster uses assignment: https://github.com/nodejs/node/pull/13761/files#diff-a8eff7604cf3ad3580c1949c54176127R57
And about cluster.settingsFortunatly we have this line in the docs:

This object is not intended to be changed or set manually.

So we can be sure noone is using it directly 😜 🤣
You could use a getter on cluster.settings to defensively mark it dirty-on-read
And BTW, Proxies are not that bad... Cumbersome but useful.

Next PR turn cluster.settings into a deep-copy getter, and rename setupMaster to setup.

@mutantcornholio
Copy link
Contributor Author

So we can be sure noone is using it directly 😜 🤣

I just looked at my codebase and it shows that I've been using it directly for almost two years :D

Next PR turn cluster.settings into a deep-copy getter, and rename setupMaster to setup.
This object is not intended to be changed or set manually

Are you saying that we should enforce setting cluster.settings through cluster.setup?
Make cluster.settings a getter (which will return a hidden object) + noop/throwing setter, for instance.

Looks better than a warning in docs, for me.

@refack
Copy link
Contributor

refack commented Jun 20, 2017

Are you saying that we should enforce setting cluster.settings through cluster.setup?
Make cluster.settings a getter (which will return a hidden object) + noop/throwing setter, for instance.

Yes enforcing, since there is quite a bit of logic in setupMaster. Returning an immutable copy on cluser.settings, should be good.
Also setupMaster should do a deep-copy, since util._extend(settings, cluster.settings); is shallow and I can do:

const smartAlec = ['myarg'];
cluster.setupMaster({execArgv: smartAlec});
smartAlec.push('--invalid');
smartAlec.shift();

@mcollina
Copy link
Member

I'm a bit lost on the status of this. It seems the two points @mutantcornholio raised are still not addressed, right?

@mutantcornholio
Copy link
Contributor Author

Well, first one is pretty straightforward and I'll just use a bigger regex.

For the second one, preventing cluster.settings from direct change and moving port override logic to setupMaster should do the trick. I guess, everything's settled and I will update the PR in couple of days.

P.S. Is it okay to do setupMaster enforcing in this PR? That looks like a bigger scope issue than overriding inspect port increment logic.

@mcollina
Copy link
Member

P.S. Is it okay to do setupMaster enforcing in this PR? That looks like a bigger scope issue than overriding inspect port increment logic.

Can you explain/rephrase this?

@mutantcornholio
Copy link
Contributor Author

https://github.com/nodejs/node/blob/master/doc/api/cluster.md#clustersettings says "This object is not intended to be changed or set manually."

I need to detect setting debug args to cluster.settings.execArgv for this.
Considering it's an array, it's not gonna be pretty.

So @refack suggested to forbid users to make changes to cluster.settings directly and enforce setting it through cluster.setupMaster.

That will make my task much easier, but should I do both tasks in one PR?

@refack
Copy link
Contributor

refack commented Jun 21, 2017

P.S. Is it okay to do setupMaster enforcing in this PR? That looks like a bigger scope issue than overriding inspect port increment logic.

IMHO that should be in a separate PR, so this one can stay semver-patch since it fixes a known-limitation.

@mutantcornholio
Copy link
Contributor Author

That way, I'll probably won't fix --inspect=0 case until next PR gets landed

@refack
Copy link
Contributor

refack commented Jun 21, 2017

That way, I'll probably won't fix --inspect=0 case until next PR gets landed

Incremental progression is good...

@refack
Copy link
Contributor

refack commented Jun 21, 2017

That way, I'll probably won't fix --inspect=0 case until next PR gets landed

cluster.setupMaster({execArgv: ['--inspect', '--inspect-port=0']}); should work after this PR, no?

@mutantcornholio
Copy link
Contributor Author

cluster.setupMaster({execArgv: ['--inspect', '--inspect-port=0']}); should work after this PR, no?

If master starts with same debug args as worker, code of this PR won't detect it. But you can start master with ['--inspect=0'] and call setupMaster with execArgv: ['--inspect', '--inspect-port=0'] and that'll do.

@mutantcornholio mutantcornholio force-pushed the cluster-inspect-override branch 2 times, most recently from 57ea09c to 7ce2925 Compare June 28, 2017 20:30
Current cluster inspect port logic doen't let user to manually set
inspect port for workers.
After this commit, adding any --inspect* options to
execArgv in cluster.setupMaster's options will disable port autoincrement
@mutantcornholio
Copy link
Contributor Author

I've got a little different idea.

Check these parts of cluster docs:
cluster.settings ... This object is not intended to be changed or set manually.
cluster.setupMaster ... the defaults above apply to the first call only, the defaults for later calls is the current value at the time of cluster.setupMaster() is called

So, once I call setupMaster({execArgv: ['--inspect=12312']}), port incrementing logic should stay overridden, no matter with what I'll call setupMaster() later.

Considering this, just checking execArgv passed to setupMaster() until catching port setting option looks sufficient.
--inspect=0 case is covered too.

I've updated the code and tests (run CI please).
If everyone agrees with solution, I'll start documenting this.

cc/ @refack @Trott @mcollina

@@ -41,15 +42,15 @@ if (schedulingPolicy === undefined) {

cluster.schedulingPolicy = schedulingPolicy;

cluster.setupMaster = function(options) {
cluster.setupMaster = function(options = {}) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a silly one, but this might be a breaking change, but IMHO we should keep it unless someone objects.
This changes the .length of the method:

> require('cluster').setupMaster.length
1
> (function a(a1) {}).length
1
> (function b(b1={}) {}).length
0

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely a breaking change, albeit a subtle one. Setting an argument default necessarily makes this semver-major

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jasnell Can you explain why? It’s not obvious to me how this would break code that isn’t designed specifically to be broken by this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why its backwards incompatible, but it is unnecessary, as is util._extend(settings, options || {}). _extend() ignores non-object second args. Default here should be removed, and the || {} that is removed below can stay removed.

@@ -26,6 +26,7 @@ cluster.SCHED_RR = SCHED_RR; // Master distributes connections.
var ids = 0;
var debugPortOffset = 1;
var initialized = false;
let debugSettingsOverriden = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a global, augh...
 💡
🤓
create a Symbol and hang it on cluster.settings

const kDebugSettingsOverriden = Symbol('Debug Settings Overriden');
...
    var settings = {
      args: process.argv.slice(2),
      exec: process.argv[1],
      execArgv: process.execArgv,
      silent: false,
      [kDebugSettingsOverriden]: false
    };

What the heck, hang them all (maybe in the different PR though)

@@ -60,6 +61,14 @@ cluster.setupMaster = function(options) {
settings.execArgv = settings.execArgv.concat(['--logfile=v8-%p.log']);
}

// This allows user to override inspect port for workers.
const debugPortArgsRegex = /--inspect(=|-port=)|--debug-port=/;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const debugOverrideInSettings = options.execArgv && options.execArgv.some((arg) => arg.match(debugPortArgsRegex))
settings.execArgv[kDebugSettingsInArgv] = settings.execArgv.some((arg) => arg.match(/--inspect(?:-brk|-port)?|--debug-port/)))

Or some variation of... Then reuse

@refack
Copy link
Contributor

refack commented Jun 28, 2017

I like it. It's simple!
If I get it right now the known limitation is:

cluster.setupMaster({execArgv: ['--inspect=12312']});
fork() // goes to 12312
cluster.setupMaster({execArgv: [--inspect]});
fork() // goes to 9229
fork() // boom

@refack
Copy link
Contributor

refack commented Jun 28, 2017

💥
🤓
Same code but expose [kDebugSettingsOverriden]: false as a new public property of settings you can undo, or set to a number, or a lambda, or a web-service, or....

cluster.setupMaster({execArgv: ['--inspect=12312']});
fork() // goes to 12312
cluster.setupMaster({execArgv: [--inspect], overideDebugPort: false});
fork() // goes to 9229
fork() // goes to 9230
let port = 6666;
cluster.setupMaster({execArgv: [--inspect], overideDebugPort: () => port++});
fork() // goes to 6666
fork() // goes to 6667

@Trott Trott requested a review from bnoordhuis June 29, 2017 02:42
@mutantcornholio
Copy link
Contributor Author

Same code but expose [kDebugSettingsOverriden]: false as a new public property of settings you can undo, or set to a number, or a lambda, or a web-service, or....

I thought about that:

So maybe instead of this, I should just add inspectPort option right to cluster.settings?

Maybe we should do that instead. Boolean option to disable autoincrement logic?

@jasnell jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jun 30, 2017
@jasnell
Copy link
Member

jasnell commented Jun 30, 2017

Quick glance through the code looks good but didn't go through enough to sign off. I will say that it would be helpful to include some details about this in the docs.

var settings = {
args: process.argv.slice(2),
exec: process.argv[1],
execArgv: process.execArgv,
silent: false
};
util._extend(settings, cluster.settings);
util._extend(settings, options || {});
util._extend(settings, options);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, the || {} was unnecessary, _extend() already does the right thing.

@refack
Copy link
Contributor

refack commented Jun 30, 2017

Maybe we should do that instead. Boolean option to disable autoincrement logic?

This is chinatown JavaScript so I say an overloaded property inspectPort (maybe overrideInspectPort):

  • Boolean - enable / disable auto increment — negated so if (!settings.inspectPort) do the current logic
  • Number - explicit port to use
  • Function - function to run that return a number that will be the port
  • String - order a t-shirt from cafe-press with the string printed on it

@mutantcornholio
Copy link
Contributor Author

An option called inspectPort which could accept boolean doesn't sound right to me. inspectPort: true shows me that "Some inspector port is set", not "Port autoincrement logic for workers is disabled"

I'd better split it into boolean inspectPortAutoincrement and number/function inspectPort.

And setting inspectPort would override inspectPortAutoincrement setting (which would default to true, IMHO).

What do you think?

@Trott
Copy link
Member

Trott commented Jul 1, 2017

I'd better split it into boolean inspectPortAutoincrement and number/function inspectPort.

And setting inspectPort would override inspectPortAutoincrement setting (which would default to true, IMHO).

What do you think?

If you do go with an option, maybe drop the Auto and call it inspectPortIncrement or even portIncrement? I think increment is clearer than autoincrement.

@mutantcornholio
Copy link
Contributor Author

Dropping Auto sounds good, but I don't want to drop inspect — some people (like me) might think of port that workers accept connections on.

So, I'm making two explicit options and removing implicit override in execArgv?

@refack
Copy link
Contributor

refack commented Jul 2, 2017

So, I'm making two explicit options and removing implicit override in execArgv?

I'm just summarizing current thoughts:

  1. settings.execArgv.push('--inspect-port=XXX') turns off settings.inspectPortIncrement (previously known as `debugSettingsOverriden')
  2. resetting settings.execArgv does not automatically reset settings.inspectPortIncrement
  3. new option settings.inspectPort can be number or lambda () => n

Plus:

  • remove default ={} from cluster.setupMaster = function(options = {}) { since util._extend(settings, options) does the right thing anyway, and return to semver-minor again.

Things to think about:

  1. inspectPortIncrement implies opt-in to previous behaviour, and IMHO we need opt-out (so that if !'inspectPortIncrement' in settings || Boolean(settings.inspectPortIncrement) == false we do what we always did)
  2. what do we do if settings.inspectPortIncrement === false & settings.inspectPort == null?

My alternative — inspectPortOveride:

  1. if undefined act like before PR
  2. if true don't do anything
  3. if number / () => n use value for adding --inspect-port=n
  4. if cluster.setupMaster({ execArgv: ['--inspect-port=XXX')}) then implicitly we set settings.inspectPortOveride = true
  5. (4) can be reverted with cluster.setupMaster({ execArgv: [], inspectPortOveride: false}) and we go back the pre PR behaviour

oooff a lot to think about...

@mutantcornholio
Copy link
Contributor Author

settings.execArgv.push('--inspect-port=XXX') turns off settings.inspectPortIncrement (previously known as `debugSettingsOverriden')

I don't see, why we should do both settings.inspectPortIncrement and controlling it by looking in settings.execArgv. If we add an option to disable increment manually, why should we have implicit complex logic? I think using one of these methods is sufficient.
I mean, right now we have zero methods, why add two at once?

inspectPortIncrement implies opt-in to previous behaviour, and IMHO we need opt-out

Well, maybe. But we need a better name for the option, this way. Any ideas?

My alternative — inspectPortOveride:

Once again, I don't think that I would understand what {inspectPortOverride: true} could mean, without getting in the docs. I would thought "Override it with what?", not "Oh, that's disables incrementing behaviour, but the port stays the same"

@refack
Copy link
Contributor

refack commented Jul 2, 2017

I don't see, why we should do both settings.inspectPortIncrement and controlling it by looking in settings.execArgv. If we add an option to disable increment manually, why should we have implicit complex logic? I think using one of these methods is sufficient.
I mean, right now we have zero methods, why add two at once?

I'm convinced.

inspectPortIncrement implies opt-in to previous behaviour, and IMHO we need opt-out

Well, maybe. But we need a better name for the option, this way. Any ideas?

disableInspectorPortIncrement?

So:

  1. disableInspectorPortIncrement (or any other better name) — mean we do not do any argv manipulation, what comes in is what goes to the process.
  2. inspectPort — mean we add --inspector-port=N

So now I'm not sure why we need (1) as I see it (2) covers all use-cases. If inspectPort is set, we use it, if it's not, we act like before the PR? seems good enough to me... No argv mutations, just adding last arg.

@mutantcornholio
Copy link
Contributor Author

So now I'm not sure why we need (1) as I see it (2) covers all use-cases. If inspectPort is set, we use it, if it's not, we act like before the PR? seems good enough to me...

Now I am convinced.

I'll do that in a couple of days.

@mutantcornholio
Copy link
Contributor Author

Closed in favor of #14140

refack pushed a commit to mutantcornholio/node that referenced this pull request Jul 14, 2017
* Capitalization and punctuation.

* `setupMaster` contained info about `settings` which where incomplete.

PR-URL: nodejs#14140
Fixes: nodejs#8495
Fixes: nodejs#12941
Refs: nodejs#9659
Refs: nodejs#13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
refack pushed a commit to mutantcornholio/node that referenced this pull request Jul 14, 2017
10 ports for each test-case is too much.
Not enough ports for new test cases, considering ~100 ports per file.

PR-URL: nodejs#14140
Fixes: nodejs#8495
Fixes: nodejs#12941
Refs: nodejs#9659
Refs: nodejs#13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
refack pushed a commit to mutantcornholio/node that referenced this pull request Jul 14, 2017
Added an option to override inspector port for workers using
`settings.inspectPort` will override default port incrementing behavior.
Also, using this option allows to set 0 port for the whole cluster.

PR-URL: nodejs#14140
Fixes: nodejs#8495
Fixes: nodejs#12941
Refs: nodejs#9659
Refs: nodejs#13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
addaleax pushed a commit that referenced this pull request Jul 18, 2017
* Capitalization and punctuation.

* `setupMaster` contained info about `settings` which where incomplete.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
addaleax pushed a commit that referenced this pull request Jul 18, 2017
10 ports for each test-case is too much.
Not enough ports for new test cases, considering ~100 ports per file.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
addaleax pushed a commit that referenced this pull request Jul 18, 2017
Added an option to override inspector port for workers using
`settings.inspectPort` will override default port incrementing behavior.
Also, using this option allows to set 0 port for the whole cluster.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fishrock123 pushed a commit that referenced this pull request Jul 19, 2017
* Capitalization and punctuation.

* `setupMaster` contained info about `settings` which where incomplete.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fishrock123 pushed a commit that referenced this pull request Jul 19, 2017
10 ports for each test-case is too much.
Not enough ports for new test cases, considering ~100 ports per file.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Fishrock123 pushed a commit that referenced this pull request Jul 19, 2017
Added an option to override inspector port for workers using
`settings.inspectPort` will override default port incrementing behavior.
Also, using this option allows to set 0 port for the whole cluster.

PR-URL: #14140
Fixes: #8495
Fixes: #12941
Refs: #9659
Refs: #13761
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@refack refack removed their assignment Oct 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cluster Issues and PRs related to the cluster subsystem. inspector Issues and PRs related to the V8 inspector protocol semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

debugging and fork (Error: listen EADDRINUSE :::5858)
9 participants