GenericMMSError: Instance failed to start within 10000ms #771

dhruvkumar456 · 2023-06-18T13:56:54Z

Versions

NodeJS: 18.15.0
mongodb-memory-server-*: ^8.13.0
mongodb: 5.5.0,
mongoose: 7.1.1
system: Linux container (FROM --platform=linux/amd64 node:18.15.0)
process.arch: x64

package: mongo-memory-server

What is your question?

when I write this following code

const mongod = await MongoMemoryServer.create();
const mongoUri = mongod.getUri();

I get the following error

Starting the MongoMemoryServer Instance failed, enable debug log for more information. Error:
     GenericMMSError: Instance failed to start within 10000ms
        at Timeout.<anonymous> (/opt/tbo/node_modules/mongodb-memory-server-core/src/util/MongoInstance.ts:365:21)
        at listOnTimeout (node:internal/timers:569:17)
        at processTimers (node:internal/timers:512:7)

      at MongoMemoryServer.<anonymous> (../node_modules/mongodb-memory-server-core/src/MongoMemoryServer.ts:293:17)
      at ../node_modules/tslib/tslib.js:167:75
      at __awaiter (../node_modules/tslib/tslib.js:163:16)
      at ../node_modules/mongodb-memory-server-core/src/MongoMemoryServer.ts:284:68

Note: I am running docker container over m1 chip(arm64 processor).

how can I overcome these errors ?

The text was updated successfully, but these errors were encountered:

hasezoey · 2023-06-18T16:01:54Z

mongodb: 5.5.0,

i am pretty sure the template had some extra notes. assuming from the version 5.5.0 this is the driver not the binary

system: Linux container (FROM --platform=linux/amd64 node:18.15.0)

a note to self: docker image node:18.15.0 is based on debian:11, 11.6, bullseye

Note: I am running docker container over m1 chip(arm64 processor).

docker currently shipped qemu version does not support AVX instructions, which mongodb requires since 5.0 (and mongodb-memory-server's current default is a 5.x version), see #710

 GenericMMSError: Instance failed to start within 10000ms

this error should not happen and throw a actual error, could you post the full log of when this error occurs with debug logs enabled?

assuming you are using a mac with arm and running x86 docker, then your only options are:

downgrade to a 4.x mongodb version, see config option: VERSION
compile docker yourself (or somehow replace the used qemu version)
dont use docker (and either run a manual mongodb instance or run mongodb-memory-server outside of docker)

dhruvkumar456 · 2023-06-18T17:20:40Z

@hasezoey This is the full debug log:

 MongoMS:MongoMemoryServer create: Called .create() method +0ms
  MongoMS:MongoMemoryServer Mongo[unknown]: start: Called .start() method +2ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance: Called MongoMemoryServer._startUpInstance() method +2ms
  MongoMS:MongoMemoryServer Mongo[unknown]: getStartOptions: forceSamePort: false +1ms
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance: Creating new MongoDB instance with options: {
  instance: {
    port: 43153,
    dbName: '',
    ip: '127.0.0.1',
    storageEngine: 'ephemeralForTest',
    replSet: undefined,
    dbPath: '/tmp/mongo-mem-1Oj9pe',
    tmpDir: '/tmp/mongo-mem-1Oj9pe',
    keyfileLocation: undefined,
    launchTimeout: undefined,
    args: undefined,
    auth: false
  },
  binary: undefined,
  spawn: undefined
} +21ms
  MongoMS:MongoInstance create: Called .create() method +0ms
  MongoMS:MongoInstance Mongo[43153]: start +5ms
  MongoMS:MongoBinary getPath +0ms
  MongoMS:DryMongoBinary generateOptions +0ms
  MongoMS:utils tryReleaseFile: "/etc/upstream-release/lsb-release" does not exist +0ms
  MongoMS:getos getLinuxInformation: Using etcOsRelease +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +25ms
  MongoMS:DryMongoBinary generatePaths {
  version: '5.0.18',
  downloadDir: '',
  os: {
    os: 'linux',
    dist: 'debian',
    codename: 'bullseye',
    release: '11',
    id_like: undefined
  },
  platform: 'linux',
  arch: 'x64',
  systemBinary: ''
} +1ms
  MongoMS:DryMongoBinary getBinaryName +1ms
  MongoMS:DryMongoBinary combineBinaryName +8ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +1ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  legacyHomeCache: '/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18',
  modulesCache: '/opt/tbo/node_modules/.cache/mongodb-memory-server/mongod-x64-debian-5.0.18',
  relative: '/opt/tbo/mongodb-binaries/mongod-x64-debian-5.0.18',
  resolveConfig: ''
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in legacyHomeCache: "/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18" +6ms
  MongoMS:MongoBinary getPath: MongoBinary options: {
  "version": "5.0.18",
  "downloadDir": "/root/.cache/mongodb-binaries",
  "os": {
    "os": "linux",
    "dist": "debian",
    "codename": "bullseye",
    "release": "11"
  },
  "platform": "linux",
  "arch": "x64",
  "systemBinary": "",
  "checkMD5": false
} +46ms
  MongoMS:DryMongoBinary locateBinary: Trying to locate Binary for version "5.0.18" +4ms
  MongoMS:DryMongoBinary generateOptions +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +3ms
  MongoMS:DryMongoBinary generatePaths {
  version: '5.0.18',
  downloadDir: '/root/.cache/mongodb-binaries',
  os: {
    os: 'linux',
    dist: 'debian',
    codename: 'bullseye',
    release: '11',
    id_like: undefined
  },
  platform: 'linux',
  arch: 'x64',
  systemBinary: ''
} +1ms
  MongoMS:DryMongoBinary getBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +2ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generatePaths: resolveConfigValue is not empty +0ms
  MongoMS:DryMongoBinary combineBinaryName +1ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  legacyHomeCache: '/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18',
  modulesCache: '/opt/tbo/node_modules/.cache/mongodb-memory-server/mongod-x64-debian-5.0.18',
  relative: '/opt/tbo/mongodb-binaries/mongod-x64-debian-5.0.18',
  resolveConfig: '/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18'
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in resolveConfig (DOWNLOAD_DIR): "/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18" +3ms
  MongoMS:DryMongoBinary locateBinary: running generateDownloadPath +2ms
  MongoMS:DryMongoBinary generateDownloadPath: Generating Download Path, preferGlobal: "true" +1ms
  MongoMS:DryMongoBinary generatePaths {
  version: '5.0.18',
  downloadDir: '/root/.cache/mongodb-binaries',
  os: {
    os: 'linux',
    dist: 'debian',
    codename: 'bullseye',
    release: '11',
    id_like: undefined
  },
  platform: 'linux',
  arch: 'x64',
  systemBinary: ''
} +0ms
  MongoMS:DryMongoBinary getBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +1ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generatePaths: resolveConfigValue is not empty +1ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary combineBinaryName +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Paths: {
  legacyHomeCache: '/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18',
  modulesCache: '/opt/tbo/node_modules/.cache/mongodb-memory-server/mongod-x64-debian-5.0.18',
  relative: '/opt/tbo/mongodb-binaries/mongod-x64-debian-5.0.18',
  resolveConfig: '/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18'
}  +0ms
  MongoMS:DryMongoBinary generateDownloadPath: Found binary in resolveConfig (DOWNLOAD_DIR): "/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18" +1ms
  MongoMS:DryMongoBinary locateBinary: found binary at "/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18" +0ms
  MongoMS:MongoBinary getPath: Mongod binary path: "/root/.cache/mongodb-binaries/mongod-x64-debian-5.0.18" +18ms
  MongoMS:MongoInstance Mongo[43153]: start: Starting Processes +68ms
  MongoMS:MongoInstance Mongo[43153]: _launchMongod: Launching Mongod Process +1ms
  MongoMS:MongoInstance Mongo[43153]: prepareCommandArgs +1ms
  MongoMS:MongoInstance Mongo[43153]: prepareCommandArgs: final argument array:["--port","43153","--dbpath","/tmp/mongo-mem-1Oj9pe","--storageEngine","ephemeralForTest","--bind_ip","127.0.0.1","--noauth"] +0ms
  MongoMS:MongoInstance Mongo[43153]: _launchKiller: Launching Killer Process (parent: 477, child: 511) +24ms
  MongoMS:MongoInstance Mongo[43153]: constructor: Instance has thrown an Error: Error: Instance failed to start within 10000ms +10s
  MongoMS:MongoInstance Mongo[43153]: stop +4ms
  MongoMS:utils Mongo[43153] killProcess: mongodProcess: sending "SIGINT" +10s
  MongoMS:MongoMemoryServer Mongo[unknown]: _startUpInstance threw a Error:  GenericMMSError: Instance failed to start within 10000ms
    at Timeout.<anonymous> (/opt/tbo/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:150:33)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7) +10s
  MongoMS:MongoMemoryServer Mongo[unknown]: stop: Called .stop() method +4ms
  MongoMS:MongoMemoryServer Mongo[unknown]: stop: "instanceInfo" is not defined (never ran?) +0ms
Uncaught GenericMMSError: Instance failed to start within 10000ms
    at Timeout.<anonymous> (/opt/tbo/node_modules/mongodb-memory-server-core/lib/util/MongoInstance.js:150:33)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)
>   MongoMS:utils Mongo[43153] killProcess: mongodProcess: got exit signal, Code: null, Signal: SIGINT +33ms
  MongoMS:utils Mongo[43153] killProcess: killerProcess: sending "SIGINT" +3ms
  MongoMS:MongoInstance Mongo[43153]: closeHandler: Mongod instance closed with an non-0 (or non 12 on windows) code! +40ms
  MongoMS:MongoInstance Mongo[43153]: constructor: Instance has thrown an Error: Error: Instance closed unexpectedly with code "null" and signal "SIGINT" +2ms
  MongoMS:MongoInstance Mongo[43153]: stop +0ms
  MongoMS:MongoInstance Mongo[43153]: stop: mongodProcess: nothing to shutdown, skipping +0ms
  MongoMS:utils Mongo[43153] killProcess: killerProcess: sending "SIGINT" +6ms
  MongoMS:MongoInstance Mongo[43153]: closeHandler: code: "null", signal: "SIGINT" +3ms
  MongoMS:utils Mongo[43153] killProcess: killerProcess: got exit signal, Code: 0, Signal: null +23ms
  MongoMS:utils Mongo[43153] killProcess: killerProcess: got exit signal, Code: 0, Signal: null +1ms
  MongoMS:MongoInstance Mongo[43153]: stop: Instance Finished Shutdown +23ms
  MongoMS:MongoInstance Mongo[43153]: stop: Instance Finished Shutdown +1ms

I will try to downgrade to 4.x mongodb version and will update here in sometime.

dhruvkumar456 · 2023-06-18T17:53:05Z

downgrade to a 4.x mongodb version, see config option: VERSION

Downgrading mongodb to 4.x resolves my issue.

I added below config in package.json file and it worked.

"config": {
    "mongodbMemoryServer": {
      "debug": "1",
      "version": "4.2.19"
    }
  }

Thanks @hasezoey .

hasezoey · 2023-06-19T10:38:05Z

thanks for the debug log, from which it seems like no error was ever thrown and the childprocess just hangs, which the timeout was made for

sebastianfelipe · 2023-07-03T06:04:50Z

I have exactly the same issue, but I do need to use Mongo 5+ because some specific queries and configurations of the project so I can't run my unit tests (where I'm using this package), because this issue :/. How would be the workaround then? I mean, I can run MongoDB 5+ as a replicaset inside docker, but mongodb server throws this error. I tried to activate Rosetta in Docker and the error changed a little bit, saying that the CPU does not have AVX support. Anyway, is there a way to deactivate that and still using Mongo 5+?

Thank you!

hasezoey · 2023-07-03T08:38:45Z

saying that the CPU does not have AVX support. Anyway, is there a way to deactivate that and still using Mongo 5+?

to my knowledge AVX is a hard requirement for mongodb 5.0 and up and cannot be disabled for x86_64 builds (unless you somehow build from source?)

I mean, I can run MongoDB 5+ as a replicaset inside docker,

what image are you using for that?

from my knowledge there are only the following "workarounds":

downgrade to a 4.x mongodb version, see config option: VERSION (unlikely in your case as you have stated)
compile docker yourself (or somehow replace the used qemu version)
dont use docker
- run a manual mongodb instance or,
- run mongodb-memory-server outside of docker
use a separate docker image that works for you

(it is likely that a image exists which does work, but MMS only sources its binaries from the official mongodb archive, which has a hard-requirement of AVX when compiled for x86_64)

sebastianfelipe · 2023-07-03T13:48:11Z

Well, I'm using the following docker image on my M2 laptop. Believe it or not, it works on M1 (collegue machine) and on my M2 machine: v5 (d2c5bd63ff0c). This runs directly on Docker environment, with and without Rosetta activated and it is a whole ReplicaSet (3 nodes). The error happens only with Mongo Memory Server. The workaround that my friend had found was create a secondary ReplicaSet just for testing and connect to that, but that workaround should not work as that, because we are just using it for unit tests, so is too deep for that purpose.

Conclusion, there should be a configuration or something different that can be set on Mongo Memory Server that could create this Mongo resource, without throwing the AVX resource issue. If it is working outside as expected, it should be a way fix this and do it on memory.

I found the image by its difest SHA-256, this is the Docker image I'm using can be found as:
$ docker pull mongo@sha256:0204edbcce18661dbf0f4f4274e393f990b4ef4a5d2cf3f96199a2c35fc3f1f5
ImageID: d2c5bd63ff0cdf257e07237818a04c3fefd2ee541e937a1610446bb418f33a62
Referenced in Docker Hub here

hasezoey · 2023-07-03T16:54:41Z

image mongo@sha256:0204edbcce18661dbf0f4f4274e393f990b4ef4a5d2cf3f96199a2c35fc3f1f5 seems to be based on ubuntu 20.04 and is build for architecture arm64

if this works, then using ubuntu arm binaries will also work (from older experiences reading issues, i had the assumption that docker arm cannot run arm because it is using qemu x86_64 to run the containers)

note that this only works if the container you are running MMS in is also ARM64 and running ubuntu (not alpine) and you will have to overwrite the used Config option ARCHIVE_NAME for now (in a future version overwriting Config Option DISTRO should be enough)

sebastianfelipe · 2023-07-03T16:59:56Z

That assumption is right. And it works, the thing is, that is does not work with Mongo Memory Server. I tried to run it as cross-env MONGOMS_DOWNLOAD_URL=https://fastdl.mongodb.org/linux/mongodb-linux-aarch64-amazon2-5.0.18.tgz MONGOMS_VERSION=5.0.18 yarn test to pass the correct URL that I found on internet and the correct version. I tried it using arm64 in devcontainers also and nope. I mean, the error is different tho, but it still not working.

I didn't modified the ARCHIVE_NAME mmm, I suppose I need to have a look at that. Is enought what I did or I need to overwrite that too?

sebastianfelipe · 2023-07-03T17:03:39Z

What would be the correct archive name? Because I used one for Amazon instead of Ubuntu. I will give it a try. That would explain the error respect to "Binary"

hasezoey · 2023-07-03T17:03:46Z

mongodb-linux-aarch64-amazon2-5.0.18.tgz

you should not use amazon2 builds for ubuntu

I mean, the error is different tho, but it still not working.

if you want to post it you can

Is enought what I did or I need to overwrite that too?

Docs:

ARCHIVE_NAME
This Option does not have a effect when DOWNLOAD_URL is defined.

I tried it using arm64 in devcontainers also and nope. I mean, the error is different tho, but it still not working.

if the container you are running MMS in is arm64, then i dont know why the mongo container works but this not, maybe post the full debug log of when you are running a arm64 container with MMS and have ARCHIVE_NAME overwritten (or DOWNLOAD_URL)

Note: i dont have a ARM64 system to test this on (and also no mac)

sebastianfelipe · 2023-07-03T17:28:57Z

Ok, I understood the process, the thing is that the project is using node:16 image, and as dar as I know, that is Debian 10, and Mongo is not listing any Debian 10 ARM 64 archive. What do you suggest in this scenario?

hasezoey · 2023-07-03T17:49:23Z

and as dar as I know, that is Debian 10, and Mongo is not listing any Debian 10 ARM 64 archive

the ubuntu binaries can be used in a debian image from my knowledge

sebastianfelipe · 2023-07-03T17:52:06Z

I thought the same, I did the following:

I use Node 16 as base in my devcontainer
Defined the aarch64 ubuntu20.04 mongo archive
Eveything works with arm64 as expected (qemu-arm64), but when I try to run the unit tests with MMS, it breaks with error code 1

hasezoey · 2023-07-03T17:53:40Z

Eveything works with arm64 as expected (qemu-arm64), but when I try to run the unit tests with MMS, it breaks with error code 1

please provide full logs

dhruvkumar456 added the question label Jun 18, 2023

dhruvkumar456 closed this as completed Jun 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GenericMMSError: Instance failed to start within 10000ms #771

GenericMMSError: Instance failed to start within 10000ms #771

dhruvkumar456 commented Jun 18, 2023 •

edited

Loading

hasezoey commented Jun 18, 2023

dhruvkumar456 commented Jun 18, 2023

dhruvkumar456 commented Jun 18, 2023

hasezoey commented Jun 19, 2023

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

hasezoey commented Jul 3, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

hasezoey commented Jul 3, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

GenericMMSError: Instance failed to start within 10000ms #771

GenericMMSError: Instance failed to start within 10000ms #771

Comments

dhruvkumar456 commented Jun 18, 2023 • edited Loading

Versions

What is your question?

hasezoey commented Jun 18, 2023

dhruvkumar456 commented Jun 18, 2023

dhruvkumar456 commented Jun 18, 2023

hasezoey commented Jun 19, 2023

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

sebastianfelipe commented Jul 3, 2023 • edited Loading

hasezoey commented Jul 3, 2023 • edited Loading

sebastianfelipe commented Jul 3, 2023 • edited Loading

sebastianfelipe commented Jul 3, 2023 • edited Loading

hasezoey commented Jul 3, 2023 • edited Loading

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

sebastianfelipe commented Jul 3, 2023

hasezoey commented Jul 3, 2023

dhruvkumar456 commented Jun 18, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

hasezoey commented Jul 3, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

sebastianfelipe commented Jul 3, 2023 •

edited

Loading

hasezoey commented Jul 3, 2023 •

edited

Loading