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

cluster: suicide flag is not set on master when calling disconnect from a worker #3238

Closed
dpatti opened this issue Oct 7, 2015 · 5 comments
Labels
cluster Issues and PRs related to the cluster subsystem. confirmed-bug Issues with confirmed bugs.

Comments

@dpatti
Copy link

dpatti commented Oct 7, 2015

From the documentation:

worker.suicide:

Set by calling .kill() or .disconnect(), until then it is undefined.

worker.disconnect():

In a worker, this function will close all servers, wait for the 'close' event on those servers, and then disconnect the IPC channel.

Causes .suicide to be set.

Repro:

var cluster = require('cluster');

if (cluster.isMaster) {
  // Master forks and listens for events
  var worker = cluster.fork();
  cluster.on('disconnect', function(){
    console.log("disconnect", worker.suicide);
  });
  cluster.on('exit', function(){
    console.log("exit", worker.suicide);
  });
} else {
  // Worker just disconnects
  cluster.worker.disconnect();
}

In node v0.10, both log statements would print true for worker.suicide. In 41b75ca, which landed during the v0.11 branch, this was broken, and all versions up to node v4 will print false. This is because worker.disconnect(), when called from the worker, does not send the suicide message anymore -- only worker.destroy() will send that message to the master.

@mscdex mscdex added the cluster Issues and PRs related to the cluster subsystem. label Oct 7, 2015
@sam-github sam-github added the confirmed-bug Issues with confirmed bugs. label Oct 13, 2015
cjihrig added a commit to cjihrig/node that referenced this issue Nov 10, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: nodejs#3238
cjihrig added a commit that referenced this issue Nov 11, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: #3238
PR-URL: #3720
Reviewed-By: James M Snell <jasnell@gmail.com>
cjihrig added a commit that referenced this issue Nov 17, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: #3238
PR-URL: #3720
Reviewed-By: James M Snell <jasnell@gmail.com>
cjihrig added a commit that referenced this issue Dec 4, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: #3238
PR-URL: #3720
Reviewed-By: James M Snell <jasnell@gmail.com>
cjihrig added a commit that referenced this issue Dec 17, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: #3238
PR-URL: #3720
Reviewed-By: James M Snell <jasnell@gmail.com>
santigimeno added a commit to santigimeno/node that referenced this issue Dec 22, 2015
There is no guarantee that the `suicide` property of a worker in the master
process is going to be set when the `disconnect` and `exit` events are emitted.
To fix it, wait for the ACK of the suicide message from the master before
disconnecting the worker.
Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and `disconnect`
cases. Also take into account that the `disconnect` event may be received after
the `exit` event.
cjihrig added a commit that referenced this issue Dec 23, 2015
This commit causes Worker.prototype.disconnect() to send a
suicide message to the cluster master. The function is also
restructured to eliminate redundant code.

Fixes: #3238
PR-URL: #3720
Reviewed-By: James M Snell <jasnell@gmail.com>
santigimeno added a commit to santigimeno/node that referenced this issue Jan 13, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.
To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.
Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.
Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.
Trott pushed a commit to Trott/io.js that referenced this issue Jan 14, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: nodejs#4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
rvagg pushed a commit that referenced this issue Jan 14, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-GH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: #4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit that referenced this issue Jan 28, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-GH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: #4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit that referenced this issue Feb 11, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-GH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: #4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit to MylesBorins/node that referenced this issue Feb 11, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: nodejs#4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
MylesBorins pushed a commit to MylesBorins/node that referenced this issue Feb 15, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: nodejs#4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
scovetta pushed a commit to scovetta/node that referenced this issue Apr 2, 2016
There is no guarantee that the `suicide` property of a worker in the
master process is going to be set when the `disconnect` and `exit`
events are emitted.

To fix it, wait for the ACK of the suicide message from the master
before disconnecting the worker. Also, there's no need to send the
suicide message from the worker if the disconnection has been
initiated in the master.

Add `test-cluster-disconnect-suicide-race` that forks a lot of workers
to consistently reproduce the issue this patch tries to solve.

Modify `test-regress-nodejsGH-3238` so it checks both the `kill` and
`disconnect` cases. Also take into account that the `disconnect` event
may be received after the `exit` event.

PR-URL: nodejs#4349
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
@zhongkai
Copy link

Came across same problem. I set a flag called "isSuicide" of worker Object:

var cluster = require('cluster');

if (cluster.isMaster) {
  // Master forks and listens for events
  var worker = cluster.fork();
  cluster.on('disconnect', function(worker){
    worker.isSuicide = true;
    console.log("disconnect", worker.suicide);
  });
  cluster.on('exit', function(worker){
    worker.isSuicide && console.log("exit by suicide");
  });
} else {
  // Worker just disconnects
  cluster.worker.disconnect();
}

Is this a good practice for all node versions?

@sam-github
Copy link
Contributor

all versions up to node v4 will print false.

Are you saying it will print true for v5 and later?

@zhongkai No, it is not good practice. Your code sets suicide when the IPC channel is disconnected, but the 0.10 behaviour does it only when the worker deliberately disconnected.

Change your line of code cluster.worker.disconnect(); to thow 'farewall, crule world', and your code will also set your custom isSuicide property, which it should not.

@dpatti
Copy link
Author

dpatti commented Dec 21, 2016

@sam-github Note that this issue was opened over a year ago and was supposedly fixed in f299d87. I don't know what the current behavior is or what is intended.

@sam-github
Copy link
Contributor

Ah, didn't notice that. So, should be fixed. @zhongkai On what node version did you come across this problem?

@zhongkai
Copy link

@sam-github , I'm sorry. I just want to make sure the solution is OK for version 0.12.x or not?

ryzokuken added a commit to ryzokuken/node that referenced this issue Mar 7, 2018
Rename the test appropriately alongside mentioning the subsystem
Also, make a few basic changes to make sure the test conforms
to the standard test structure

Refs: nodejs#19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
BridgeAR pushed a commit to BridgeAR/node that referenced this issue Mar 11, 2018
Rename the tests appropriately alongside mentioning the subsystem.
Also, make a few basic changes to make sure the test conforms
to the standard test structure.

This renames:
- test-regress-nodejsGH-1531
- test-regress-nodejsGH-2245
- test-regress-nodejsGH-3238
- test-regress-nodejsGH-3542
- test-regress-nodejsGH-3739
- test-regress-nodejsGH-4256

PR-URL: nodejs#19212
Refs: nodejs#19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this issue Mar 17, 2018
Rename the tests appropriately alongside mentioning the subsystem.
Also, make a few basic changes to make sure the test conforms
to the standard test structure.

This renames:
- test-regress-GH-1531
- test-regress-GH-2245
- test-regress-GH-3238
- test-regress-GH-3542
- test-regress-GH-3739
- test-regress-GH-4256

PR-URL: #19212
Refs: #19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
MylesBorins pushed a commit that referenced this issue Mar 20, 2018
Rename the tests appropriately alongside mentioning the subsystem.
Also, make a few basic changes to make sure the test conforms
to the standard test structure.

This renames:
- test-regress-GH-1531
- test-regress-GH-2245
- test-regress-GH-3238
- test-regress-GH-3542
- test-regress-GH-3739
- test-regress-GH-4256

PR-URL: #19212
Refs: #19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
MayaLekova pushed a commit to MayaLekova/node that referenced this issue May 8, 2018
Rename the tests appropriately alongside mentioning the subsystem.
Also, make a few basic changes to make sure the test conforms
to the standard test structure.

This renames:
- test-regress-nodejsGH-1531
- test-regress-nodejsGH-2245
- test-regress-nodejsGH-3238
- test-regress-nodejsGH-3542
- test-regress-nodejsGH-3739
- test-regress-nodejsGH-4256

PR-URL: nodejs#19212
Refs: nodejs#19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
BethGriggs pushed a commit that referenced this issue Oct 2, 2018
Rename the tests appropriately alongside mentioning the subsystem.
Also, make a few basic changes to make sure the test conforms
to the standard test structure.

This renames:
- test-regress-GH-1531
- test-regress-GH-2245
- test-regress-GH-3238
- test-regress-GH-3542
- test-regress-GH-3739
- test-regress-GH-4256

PR-URL: #19212
Refs: #19105
Refs: https://github.com/nodejs/node/blob/master/doc/guides/writing-tests.md#test-structure
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
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. confirmed-bug Issues with confirmed bugs.
Projects
None yet
Development

No branches or pull requests

4 participants