test-cluster-disconnect-handles hanging in background on freebsd

[rvagg]

found 10 instances of this running on one of the freebsd CI machines, e.g:

iojs          97199   0.0  0.1 620772  1772  -  I    Sat09PM      0:00.09 /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd10-64/out/Release/node --debug=12346. /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd10-64/test/parallel/test-cluster-disconnect-handles.js

[rvagg]

@nodejs/testing

[Trott]

If nothing is jumping out at anyone in the code, maybe try running this test 10K times on freebsd in the stress test job and see if it fails at some point (and see if that failure causes subsequent runs to fail too). And, of course, fix whatever is causing the first failure.

I guess in the time it took me to type that out, I could have just kicked off the job. So here it is: https://ci.nodejs.org/job/node-stress-single-test/744/nodes=freebsd102-64/console

[cjihrig]

The stress test came back green. Are there any processes left behind?

[Trott]

Expanding scope a bit, judging from failures like https://ci.nodejs.org/job/node-test-commit-arm/3454/nodes=armv7-ubuntu1404/consoleFull it seems that some test somewhere is not cleaning up after itself reliably, even when it succeeds. I imagine it would manifest as a stray node process running and keeping the port open, resulting in the plethora of EADDRINUSE errors. I imagine this is a likely source of this issue. Not sure of an easy way to identify the problematic test, though. EDIT: Oh, actually, maybe this is the culprit test...

[cjihrig]

@Trott, @rvagg can this one be closed? The issues with the CI from last week seem to be cleared up.

[Trott]

I think it can be closed.

[cjihrig]

OK. Closing. Please reopen if you think it needs to be investigated further.