ECONNREFUSED in the debugger

[msprotz]

There was an internal error in Node's debugger. Please report this bug.
connect ECONNREFUSED
Error: connect ECONNREFUSED
    at exports._errnoException (util.js:746:11)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:983:19)

node --version
v0.12.0

[cjihrig]

Can you provide additional details, like code that reproduces it, or specific commands that were run?

[msprotz]

Sure, here's a snippet from my debugging session.

node debug ../TypeScript/built/local/tsc.js --projectRoot . --sourceRoot "http://localhost/editor/local/" --sourceMap --module commonjs a/a.ts 
debug>< Debugger listening on port 5858
debug>connecting to port 5858... ok
debug>break in D:\TypeScript\built\local\tsc.js:1
> 1 var ts;
  2 (function (ts) {
  3     (function (SyntaxKind) {
debug> setBreakpoint("foobar.ts", 123);
Warning: script 'foobar.ts' was not loaded yet.
> 1 var ts;
  2 (function (ts) {
  3     (function (SyntaxKind) {
  4         SyntaxKind[SyntaxKind["Unknown"] = 0] = "Unknown";
  5         SyntaxKind[SyntaxKind["EndOfFileToken"] = 1] = "EndOfFileToken";
  6         SyntaxKind[SyntaxKind["SingleLineCommentTrivia"] = 2] = "SingleLineCommentTrivia";
debug> debug> c
debug> debug>< .
debug>program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> program terminated
debug> .There was an internal error in Node's debugger. Please report this bug.
connect ECONNREFUSED
Error: connect ECONNREFUSED
    at exports._errnoException (util.js:746:11)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:983:19)

(Of course, the file I'm trying to break on doesn't exist.)

I'm on Windows, which I guess probably matters. Let me know if there's anything I can do to help further debug this.

[Trekkan]

I'm having this same issue as the OP. Node 12, on Windows. I'll have to see if I can create some sample code from what I have, but I wanted to second the issue.

[vitaliyzolotoy]

The same issue for me on node@0.12.0

[brianhevans]

I tried the code below on BOTH Windows 7 and Mac Snow Leopard and I received the same error with Node.js 0.12.0

Response from Node.js command prompt

{ [Error: connect ECONNREFUSED]
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect' }
{ [Error: socket hang up] code: 'ECONNRESET' }

Code

var http = require('http');

var makeRequest = function(message) {
  var options = {
      host: '127.0.0.1', port: 8080, path: '/', method: 'POST', headers: {
      'Content-Type': 'application/text',
      'Content-Length': message.length
    }
  }

  var request = http.request(options, function(response) {
    response.on('data', function(data) {
      console.log(data);
    });
  });

  process.on('uncaughtException', function (err) {
    console.log(err);
  });

  request.write(message);
  request.end();    
}

makeRequest('Hi!!!!');

[adiferd]

got the same issue on node@0.12.0

[dotnetCarpenter]

same symptom in my unit test; line 220. Happens on both windows and linux. node@0.12.2 etc Using http-server:

var server = httpServer.createServer({
  root: root,
  mimeType: 'fixtures/root/mime.types'
});

server.listen(8083, '127.0.0.1', this.callback);
// this.callback ->
function () {
  // give http-server an extra second before requesting
  // to not get ECONNREFUSED
  var cb = this.callback.bind(this);
  setTimeout(function () {
    request('http://127.0.0.1:8083/mime.test', cb);
  }, 1000);
}

source: https://github.com/dotnetCarpenter/http-server/blob/ecstatic/test/http-server-test.js#L156

Note, that starting the server with above options and then do the request outside the vows tests works just fine.

ref: https://github.com/indexzero/http-server/issues/35

[dotnetCarpenter]

Same for node@0.12.3

[jcollum]

I'm on 0.12.4 on OSX, seeing a similar error when running an example from RabbitMQ library. ECONNREFUSED when attempting to start a listener on port 8080. There are no listeners present on that port when I run lsof -i

edit: ok I was being dumb -- the example was trying to connect to a rabbitmq server on localhost and just throwing up a very cryptic error message. The example won't work without a rabbitmq server running, duh.

[dotnetCarpenter]

ECONNREFUSED is an error kitchen sink. Perhaps a better error message could be provided?

[steelx]

same issue.

---

/Users/ajinkya.bo/projects/nodeauth/node_modules/mongoose/node_modules/mongodb/lib/server.js:228 process.nextTick(function() { throw err; }) ^ Error: connect ECONNREFUSED at exports._errnoException (util.js:746:11)

at TCPConnectWrap.afterConnect as oncomplete

EDIT:

I forgot to run mongod service from terminal

[jcollum]

@steelx I'm betting that Mongo isn't listening on the port/server combination that you specified. Can you isolate by testing it with RoboMongo or something?

[steelx]

@jcollum omg sorry. Yes, i forgot to run mongod service. on mac

[udaiveerS]

Maybe it might be helpful if it gave a actual line number corresponding to the function that throws the error. I do not like the express generator because it messes up any line number or errors. I don't know where server.js is or what 200 line means, the error was thrown in app.js....

sorry for the vent but I too forgot to run mongod too -_-.....

[mwkaicz]

In my case problem occures when remote service isn't online, can't response or whatever else. But problem is that timeout doesn't works correctly at this point and whole app crashes.

I got ECONNREFUSED and ETIMEDOUT, same like guy here: http://stackoverflow.com/questions/31770975/nodejs-working-http-proxy-sometimes-throws-error-connect-econnrefused

my code:

var https = require('https');
username = 'Notch';
var options = {
    hostname: 'api.mojang.com',
    port: 443,
    path: ('/users/profiles/minecraft/' + username ),
    method: 'GET',
    header: 'Content-type: application/json\r\n',
    timeout: 3
  };

  var req = https.request(options, function(response) {
    var responseData = '';
    response.setEncoding('utf8');

    response.on('data', function(chunk){
      responseData += chunk;
    });

    response.once('error', function(err){
      sails.log.warn(options.hostname + ":" + options.port + options.path, err);
      callback();
    });

    response.on('end', function(){ 
       try {
        var resp = JSON.parse(responseData);
        callback();
      } catch (e) {
        sails.log.warn(options.hostname + ":" + options.port + options.path, 'RESPONSE: "' + responseData + '"', 'Could not parse response: ' + e);
        callback();
      }
   });
}).end();

result when api.mojang doesn't responding:

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: connect ETIMEDOUT
    at exports._errnoException (util.js:746:11)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1010:19)

when I put there req.setTimeout with req.abort() before req.end(), error changes in to:

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: socket hang up
    at createHangUpError (_http_client.js:215:15)
    at TLSSocket.socketCloseListener (_http_client.js:247:23)
    at TLSSocket.emit (events.js:129:20)
    at TCP.close (net.js:485:12)

In both cases App crashes.

[jcollum]

I feel like Ben Nidal (I can't remember the name of the guy, but that's close and he has a great blog) or someone needs to write a big ol' blog post about tracking down the source for ECONNREFUSED errors.

[mwkaicz]

omg, whole problem was in port @#!

few days ago it works correctly with 443, now it works only sometimes. When I removed port from options it works correctly everytime.

[dotnetCarpenter]

@udaiveerS Unfortunately, line numbers in the Error class has not been standardized and V8 does not natively support line numbers when errors are thrown.

But node could augment the Error class via prototype and add approximately line numbers in the nearest try/catch. If the try/catch simply re-throws the error, then we (as developers) could add line numbers to the errors that we throw and know that node would preserve them. But anyway, it's a work around. We, as a community, should nag the people participating on the es-discuss list to standardize fileName, lineNumber parameters as implemented in firefox.

@jcollum his name is Ben Nadel

[mwkaicz]

One point is error handling and reporting, but other point is the fact that one wrong used port in request can crash whole node app. :(

[dotnetCarpenter]

@mwkaicz I don't know what to answer to that... It's a fundamental thing about networking. Any app would crash if you're using the wrong port. How would that even work if an app was allowed to use a port that another app is using. Sounds like that would be a huge security hole.

[mwkaicz]

@dotnetCarpenter: Sorry, but I think that some error report that port is used, doesn't responding or what ever else is better than crash whole app. I don't remember if I have ever seen some browser crash when server on requested port doesn't responds.

[MaherSoua]

Hi, this problem occur when the server stopped, you have to run node server in a terminal, and open another terminal and launch the other file.