Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

crash six minutes after launch when not connected to internet (but DNS resolution available)

See original GitHub issue

Setup

I’ve deployed Cloud Commander on a Docker containe based on coderaiser/cloudcmd:latest (latest as of the timestamp of this issue). I have not extended the image. I’ve restricted the container to an internal network, which means any connection to a host outside this network will fail. The container is still able to resolve domain names in spite of it being on an internal network.

Version (cloudcmd -v): v14.3.9 (per Docker container)
Node Version node -v: v12.16.2(per Docker container)
OS (uname -a on Linux): Linux [hostname redacted] 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux (per Docker container)
Browser name/version: n/a
Used Command Line Parameters: none
Changed Config:

{
	"name" : "[redacted]",
	"auth" : true,
	"username" : "[redacted]",
	"password" : "[redacted]",
	"algo" : "sha512WithRSAEncryption",
	"root" : "[redacted]",
	"showConfig" : true,
	"oneFilePanel" : true,
	"log" : true,
	"contact" : false,
	"importListen" : true,
	"online" : false,
	"configAuth" : false
}

Description

I’ve set up Cloud Commander in a Docker container on an internal network (i.e. no internet access). Roughly 6 minutes after launch, the Cloud Commander exits with a non-zero code and an error message (see below) after failing to connect to a remote address. These crashes occur independently of whether or not I’m connected to Cloud Command via a browser.

It appears that Cloud Commander is making a connection to registry.npmjs.org which times out. The container was able to resolve the domain to 104.16.21.35. I don’t know if this would have any relevance to the crash here since I don’t know if the crash would be any different if the container could not do DNS queries. I will see if disabling DNS resolution makes a difference.

connect ETIMEDOUT 104.16.21.35:443 Promise {
  <rejected> GotError [RequestError]: connect ETIMEDOUT 104.16.21.35:443
      at ClientRequest.<anonymous> (/usr/src/app/node_modules/package-json/node_modules/got/source/request-as-event-emitter.js:178:14)
      at Object.onceWrapper (events.js:417:26)
      at ClientRequest.emit (events.js:322:22)
      at ClientRequest.origin.emit (/usr/src/app/node_modules/package-json/node_modules/@szmarczak/http-timer/source/index.js:37:11)
      at TLSSocket.socketErrorListener (_http_client.js:426:9)
      at TLSSocket.emit (events.js:310:20)
      at emitErrorNT (internal/streams/destroy.js:92:8)
      at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
      at processTicksAndRejections (internal/process/task_queues.js:84:21) {
    name: 'RequestError',
    code: 'ETIMEDOUT',
    host: undefined,
    hostname: 'registry.npmjs.org',
    method: 'GET',
    path: '/cloudcmd',
    socketPath: undefined,
    protocol: 'https:',
    url: 'https://registry.npmjs.org/cloudcmd',
    gotOptions: {
      path: '/cloudcmd',
      protocol: 'https:',
      hostname: 'registry.npmjs.org',
      hash: '',
      search: '',
      pathname: '/cloudcmd',
      href: 'https://registry.npmjs.org/cloudcmd',
      retry: [Object],
      headers: [Object],
      hooks: [Object],
      decompress: true,
      throwHttpErrors: true,
      followRedirect: true,
      stream: false,
      form: false,
      json: true,
      cache: false,
      useElectronNet: false,
      agent: [Agent],
      method: 'GET',
      forceRefresh: true
    }
  }
}