LearnBoost / cluster

Node.JS multi-core server manager with plugins support.

Home Page:http://learnboost.github.com/cluster

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CLI hangs upon issuing stop/status/--help

zancarius opened this issue · comments

I apologize if this was mentioned elsewhere. I searched the issues list and couldn't find anything similar. I likely overlooked a similar report.

I recently upgraded Cluster to 0.7.3 on one of our development projects, and it appears that the CLI commands stop, restart, status, --help, etc. work but cause the invoked script (that is, the one running the CLI command) to hang. I'm honestly not sure what I'm doing wrong. Here's what I've tried:

  1. Assuming that it was due to some bizarre conflict with other Node modules, I created a bare directory, installed Cluster (via npm), copied out cli.js from the cluster/examples distribution, modified it to work (changing only the require() line to "cluster"), and then issued a node cli.js stop from another terminal. While this killed the master process (expected), the "stop" command hung.

  2. At this point, I was convinced it was something borked in my Node install, so I fired up a virtual machine running Arch (my main dev. box is currently running Gentoo) to ensure that my Node install was at a known clean state at version 0.4.11. I'm not sure precisely which version of Cluster I was using previously, but my ~/.npm/cluster directory contains 0.7.1 as well. So, on a whim, I cloned the Github repo and checked out 0.7.1. This version appears to work as expected; i.e. node cli.js stop will kill the cli.js script as expected then immediately terminate. Using the master branch appears to exhibit the same problem as 0.7.3.

  3. Issuing a restart appears to kill the master cluster process and spawns another worker in its place. Issuing a stop immediately thereafter will kill the worker processes as expected. Both commands freeze until interrupted with ctrl+c.

The issue isn't particularly annoying since it isn't often that we use (or expect to use) the CLI commands except for the purpose of convenience, but I'm puzzled. While I've tried the cli.js example on two different boxes, both of them are Linux, and I can't help but wonder if it's something specific to my configuration preferences.

Apologies for another repost so soon.

It appears that the cli.js example works fine as soon as I add .set("socket path", "./") (/tmp works, too). It appears this was likely caused by late-night induced stupidity on my part, so I'm going to go ahead and close this ticket.

Edit: I made a grotesque mistake and had forgotten to switch my repo back to the master, hence why the above worked (my repo was back at 0.7.1 where "socket path" appears to still exist). If I'm reading the diffs correctly, it appears that the IPC code was switched to use UDP? I'm going to reopen this ticket, because I can only surmise that it must be a configuration issue on my end that isn't playing nicely with Cluster.

looking into it

This still appears to be occurring in cluster 0.7.5, are you sure this is fixed?
Calling a node project.js status still hangs.

hmm it works fine for me, I suspect maybe there are some connections keeping the loop active

This is even when the cluster has a status of dead on all of its children and I run status again.
I'll verify there isn't an external reason why this is happening and try the latest version on a fresh project for science.

Hm, I wrote a skeleton project and it's still hanging.

// wow.js
require('cluster')('./wow-app')
  .use(cluster.logger('logs'))
  .use(cluster.stats())
  .use(cluster.pidfiles('pids'))
  .use(cluster.cli())
  .use(cluster.reload())
  .use(cluster.repl(8888))
  .listen(3000);

// wow-app.js
var express = require('express'),
    app = module.exports = express.createServer();

app.configure(function () {
});

npm install output was:
express@2.4.6 ./node_modules/express
├── mime@1.2.4
├── qs@0.3.1
└── connect@1.7.1
cluster@0.7.5 ./node_modules/cluster
├── mkdirp@0.0.7
└── log@1.2.0

Just launching with:
$ node wow.js
Then issuing a status:
$ node wow.js status

The status call shows the output but never exits (need to force it to quit).

hmm maybe we should put the explicit exit() calls back in, there are so many things that can make it hang