[1.6b23] tests fails on startup: MongoError: not master and slaveOk=false #9026

hexsprite · 2017-08-18T23:56:54Z

Some important notes:

only happens during tests, not normal app running

Getting "MongoError: not master and slaveOk=false" since updating to beta.18. I even tried adding the mongo-dev-server package but still the same. Fine if rollback to 17. Also present in b23.

I've tried this in devel branch and can reliably avoid the problem by adding a 2000ms sleep after the "Started MongoDB" message is printed. So it seems like a possible race condition of some sort where Meteor thinks MongoDB is ready but it really isn't.

When I have more spare time I'll try to put together a repro but perhaps this may have given you some clues.

MongoError: not master and slaveOk=false
    at Function.MongoError.create (/Users/jbb/.meteor/packages/npm-mongo/.2.2.30.fp9dlr.i1hfs++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/error.js:31:11)
    at queryCallback (/Users/jbb/.meteor/packages/npm-mongo/.2.2.30.fp9dlr.i1hfs++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/cursor.js:212:36)
    at /Users/jbb/.meteor/packages/npm-mongo/.2.2.30.fp9dlr.i1hfs++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:469:18
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)

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

abernix · 2017-08-23T11:36:20Z

I haven't seen this problem so far in Meteor 1.6-beta.* so a reproduction of sorts would be most helpful as I'm not sure how else to debug your problem. Do you have your own MONGO_URL setup?

I might suggest running Meteor from a checkout and adding some debug statements in the initiateReplSetAndWaitForReady method of run-mongo.js, which is where we decide that Mongo is "ready"!

hexsprite · 2017-08-31T21:37:49Z

so frustrating, it doesn't seem to fail from a checkout, only from a release

hexsprite · 2017-08-31T21:38:08Z

no custom MONGO_URL

hexsprite · 2017-08-31T21:49:34Z

Problem is still in b24. I managed to capture the Mongo logs and everything seems to be the same except that in the failure situation it seems to open 2 connections instead of 7 on success.

Update: number of connections seems to vary between runs, so that's not it

Here is the MongoD output.

https://gist.github.com/hexsprite/e563eed0898bc60b6969e774fc0b4e33

hexsprite · 2017-08-31T23:15:03Z

Doing some further debugging, I can see that Meteor successfully starts Mongo. It initially starts as a SECONDARY and then after waiting for some time it achieves the PRIMARY status.

However, when the Meteor app is connecting the response from Mongo server indicates that it is NOT a primary.

If I run the tests without --once then when the app restarts it works fine.

The gist shows some of the debugging output:

https://gist.github.com/hexsprite/e563eed0898bc60b6969e774fc0b4e33#file-more-debug-logs

hexsprite · 2017-09-01T00:41:53Z

Also tested with Mongo versions back to 3.2.12 and 3.2.16 (newer) as well. Same issue.

newer npm mongo 2.2.31 doesn't help. Nor does rolling back to 2.2.24

What does help is adding: if (Meteor.isTest || Meteor.isAppTest) { Meteor._sleepForMs(500) } before the connections are established

hexsprite · 2017-09-01T01:00:38Z

I believe a related traceback I was getting from my CI server

=> Started proxy.
Error starting Mongo (2 tries left): connection 0 to 127.0.0.1:9501 timed out
=> Started MongoDB.
/home/circleci/.meteor/packages/meteor-tool/.1.6.0-beta.26.167z5qh++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280
						throw(ex);
						^

Error: $MONGO_OPLOG_URL must be set to the 'local' database of a Mongo replica set
    at OplogHandle._startTailing (packages/mongo/oplog_tailing.js:218:13)
    at new OplogHandle (packages/mongo/oplog_tailing.js:76:8)
    at new MongoConnection (packages/mongo/mongo_driver.js:214:25)
    at new MongoInternals.RemoteCollectionDriver (packages/mongo/remote_collection_driver.js:4:16)
    at Object.<anonymous> (packages/mongo/remote_collection_driver.js:38:10)
    at Object.defaultRemoteCollectionDriver (packages/underscore.js:784:19)
    at new Mongo.Collection (packages/mongo/collection.js:99:40)
    at AccountsServer.AccountsCommon (packages/accounts-base/accounts_common.js:23:18)
    at AccountsServer (packages/accounts-base/accounts_server.js:18:5)
    at server_main.js (packages/accounts-base/server_main.js:9:12)

abernix · 2017-09-14T07:28:09Z

I don't have a solution, but just so you know you're not alone: An internal team at MDG has reported experiencing this as well:

MongoError: not master and slaveOk=false

timbotnik · 2017-09-14T23:29:59Z

After spending some time debugging this with @abernix yesterday, we determined a few things:
a) this is happening on Meteor 1.5.2 as well.
b) after forcibly upgrading the version of mongo to 3.2.16 inside the meteor tool, we could not reproduce the failure.

hexsprite · 2017-09-15T06:52:36Z

Oh, good to know! This has been driving me crazy, especially on the CI server side especially.

I updated the traceback I posted above with of the preceding lines of output as well since it seemed relevant: #9026 (comment)

abernix · 2017-09-15T10:28:30Z

@hexsprite Can you try downloading https://fastdl.mongodb.org/osx/mongodb-osx-x86_64-3.2.16.tgz and putting the bin/mongod and bin/mongo from that tarball into your meteor-tool's dev_bundle/mongodb/bin directory (replacing the two existing files)?

The exact location of the dev_bundle varies depending on what version of Meteor you're using, but the dev_bundle symlink in your project's .meteor/local/ directory should point to the right place. This means that the bin/mongod and bin/mongo files from the tarball should be placed into <app_dir>/.meteor/local/dev_bundle/mongodb/bin.

You can confirm that you've successfully replaced the correct files by running meteor mongo in your application:

$ meteor mongo
MongoDB shell version: 3.2.16
connecting to: 127.0.0.1:3001/meteor
meteor:PRIMARY> db.version()
3.2.16

Both the MongoDB shell version (the client version) and the result of db.version() (the server version) should return 3.2.16 if it's updated properly.

remotealex · 2017-09-19T07:25:06Z

I'm having the same issue and upgrading to 3.2.16 using the instructions from @abernix didn't resolve my issue. I'm currently on beta.27. Anything I can do to help?

abernix · 2017-09-19T08:28:45Z

@alexpriceonline What about downgrading the mongo to 3.2.12 (which is what it was before)? So, assuming you're on macOS (which the above instructions also assumed) same instructions as before, except with https://fastdl.mongodb.org/osx/mongodb-osx-x86_64-3.2.12.tgz.

remotealex · 2017-09-19T08:35:33Z

@abernix Thanks, but no dice. Same error using 3.2.12 (on beta.27 still).

abernix · 2017-09-19T11:21:15Z

@alexpriceonline Is this happening to you on a new project as well?

remotealex · 2017-09-19T12:13:53Z

@abernix This project is only a few days old

abernix · 2017-09-20T08:29:10Z

I experienced this, even with my own suggestions (above) applied. I'm working to reliably reproduce it and find the cause.

remotealex · 2017-09-20T09:06:42Z

@abernix Great. Let me know if there is anything I can help with.

abernix · 2017-09-20T13:25:25Z

Ok, I'm able to reproduce this, outside of tests even, with Meteor versions back to at least 1.4.4.3.

It happens frequently, in development (i.e. when running our own local Mongo), after the database database configuration has been cleared (that is to say rm -rf <appdir>/.meteor/local/db), though still doesn't happen every time so this reproduction is still flaky (It helps when my CPU is pegged for other reasons).

It makes perfect sense that it would happen under meteor test ... conditions repeatedly, since each new full test suite execution would be initiating a new database configuration (and fake replica set) for the test.

The race condition isn't too hard to see. Essentially, when a fresh replica set is being created on the new Mongo configuration, the replSetReadyToBeInitiated portion of the conditional here:

meteor/tools/runners/run-mongo.js

Lines 515 to 520 in b2df97b

    
           maybeReadyToTalk = function () { 
        
             if (resolve && 
        
                 listening && 
        
                 (noOplog || replSetReadyToBeInitiated || replSetReady)) { 
        
               proc.stdout.removeListener('data', stdoutOnData); 
        
               resolve();

...is satisfied prior to the replica set actually being elected as the new primary. I believe this is due to an idle interval in the MongoDB replica set "heartbeat", which isn't fully reflected until the next heartbeat. This is indicated by this (heavily edited) log. Mongo logs start with MONGO and my notes start with ^^ or *:

=> Running Meteor from a checkout
[[[[[ ~/Dev/Misc/Meteor/tests/mongo-miss ]]]]]
=> Started proxy.

... trying to get mongo started ...
MONGO: I CONTROL  [initandlisten] MongoDB starting : pid=89940 port=3001 dbpath=.meteor/local/db 64-bit

MONGO: I NETWORK  [initandlisten] waiting for connections on port 3001

readyToTalkPromise has been resolved (ALREADY!)
** replicaset is NOT READY YET.  initiating replicaset **
MONGO: I REPL     [conn1] replSetInitiate config object with 1 members parses ok
MONGO: I REPL     [ReplicationExecutor] New replica set config in use: { ... }
MONGO: I REPL     [ReplicationExecutor] transition to STARTUP2
MONGO: I REPL     [conn1] Starting replication applier threads
MONGO: I COMMAND  [conn1] command local.replset.minvalid command: replSetInitiate { ... } protocol:op_query 139ms
MONGO: I REPL     [ReplicationExecutor] transition to RECOVERING
MONGO: I REPL     [ReplicationExecutor] transition to SECONDARY
MONGO: I REPL     [ReplicationExecutor] conducting a dry run election to see if we could be elected
MONGO: I REPL     [ReplicationExecutor] dry election run succeeded, running for election

waiting for election...
replicaSet State: SECONDARY
replicaSet State: SECONDARY
replicaSet State: SECONDARY
replicaSet State: SECONDARY
MONGO: I REPL     [ReplicationExecutor] election succeeded, assuming primary role in term 1
MONGO: I REPL     [ReplicationExecutor] transition to PRIMARY

replicaSet State: PRIMARY
^^^ We think this means things are ready, but they really aren't yet.
=> Started MongoDB.
^^^ The application has began its startup now!

MONGO: I NETWORK  [initandlisten] connection accepted from 127.0.0.1:49890 #2 (1 connection now open)
MONGO: I NETWORK  [initandlisten] connection accepted from 127.0.0.1:49891 #3 (2 connections now open)
MONGO: I NETWORK  [initandlisten] connection accepted from 127.0.0.1:49892 #4 (3 connections now open)
^^^ this is the application connecting and getting ready to do things.
* First write to the database by accounts-base (for Meteor.users)
* Error: MongoError: not master and slaveOk=false
=> Exited with code: 1


MONGO: I REPL     [rsSync] transition to primary complete; database writes are now permitted
^^^ This is ACTUALLY when the database is ready for writes though!

Since the initiateReplSetAndWaitForReady method doesn't have access to those logs since it's separate from the launchOneMongoAndWaitForReadyForInitiate method, we have to rely on the result of replSetGetStatus (more commonly accessed through rs.status() in the mongo shell).

I'm guessing this is more pronounced now that Node.js 8 actually starts applications faster.

Fix incoming!

> Prologue: A heartbeat is used amongst members of a MongoDB replica set to poll the status of said members. When we are initiating a new replicaset for the test Mongo server, the replicaset is not fully prepared to accept writes until the voting members have negotiated and propagated their decision about who is the "primary" to all members involved. This seems to be delayed by almost _exactly_ the default heartbeat interval, which is 2000ms. The heartbeat interval is marked as an "internal only" property in Mongo so I was hesitant to lower it. It's also a new property in Mongo 3.2 which might explain why this cropped up a while ago. I believe this heartbeat delay is the only explanation for why the `rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the `mongod` has actually printed "transition to primary complete" to the log. Fixes #9026.

znerol · 2017-09-20T14:14:01Z

Oh, that makes sense. Also I expect that the (maybe single virtual) CPU is quite clogged on CI as well.

…tion. (#9119) * When awaiting Mongo, wait until the heartbeat has pulsed after election. > Prologue: A heartbeat is used amongst members of a MongoDB replica set to poll the status of said members. When we are initiating a new replicaset for the test Mongo server, the replicaset is not fully prepared to accept writes until the voting members have negotiated and propagated their decision about who is the "primary" to all members involved. This seems to be delayed by almost _exactly_ the default heartbeat interval, which is 2000ms. The heartbeat interval is marked as an "internal only" property in Mongo so I was hesitant to lower it. It's also a new property in Mongo 3.2 which might explain why this cropped up a while ago. I believe this heartbeat delay is the only explanation for why the `rs.status()` (i.e. `replSetGetStatus`) believes it is ready before the `mongod` has actually printed "transition to primary complete" to the log. Fixes #9026. * Replace addl. variable occurrence with the new `firstMemberState` var.

yanickrochon · 2017-11-27T13:38:46Z

What's the resolution for this? I had to cleanup my node_modules folder (because npm) and when I re-installed everything, I had issues with node-gyp. I resolved that, but now I get the exact same problem. App in development mode works fine so far, but running tests immediately fail with this error.

yanickrochon · 2017-11-27T14:21:43Z

I had only mongodb-tools installed (Arch), so I installed the mongodb package, and it all did go away. Not sure if this is what actually resolved it as I had other standing errors (node-fibers and node-gyp, among others), but this one disappeared with this.

hexsprite · 2017-11-28T22:39:24Z

still happening for me using Meteor 1.6.0

yanickrochon · 2017-11-28T23:16:23Z

Yeah, I saw it again, today, along with Factory.create returning undefined at random... not sure if it's related.

yanickrochon · 2017-11-30T13:26:34Z

So, this was closed two months ago, but the problem is there there! What can we do to help debug this? It suddenly happened to me when I did a meteor --reset when I attempted to fix a dependency issue (from npm and node-gyp). Never had this before.

yanickrochon · 2017-11-30T13:46:23Z

In an attempt at finding a solution, I cleaned everything from the project

$ meteor reset
$ rm -Rf node_modules/ package-lock.json
$ meteor update
$ meteor npm i

And I noticed this :

Changes to your project's package version selections from updating package versions:

coffeescript           downgraded from 1.12.7_3 to 1.12.6_1
coffeescript-compiler  removed from your project

I thought that, maybe, something with CoffeeScript was breaking and reverting would work. But, no, it did not. Instead, I had this issue on the client, while running tests : Uncaught TypeError: MochaRunner.runEverywhere is not a function.

Well, the proposed solution is to upgrade to 1.12.7_3, right?

$ meteor update --all-packages
This project is already at Meteor 1.6, the latest release.

Changes to your project's package version selections from updating package versions:

coffeescript           upgraded from 1.12.6_1 to 1.12.7_3
coffeescript-compiler  added, version 1.12.7_3

Well... good.. I guess?

$ meteor npm test

> app-name@ test /home/yanick/dev/app-name
> meteor test --driver-package practicalmeteor:mocha --port 3100

[[[[[ Tests ]]]]]

=> Started proxy.
=> Started MongoDB.
W20171130-08:37:43.871(-5)? (STDERR)
W20171130-08:37:43.888(-5)? (STDERR) /home/yanick/.meteor/packages/meteor-tool/.1.6.0.1whvdik.oongk++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-
lib/node_modules/fibers/future.js:313
W20171130-08:37:43.889(-5)? (STDERR)                                            throw(ex);
W20171130-08:37:43.889(-5)? (STDERR)                                            ^
W20171130-08:37:43.889(-5)? (STDERR) MongoError: not master and slaveOk=false

W20171130-08:37:43.889(-5)? (STDERR)     at Function.MongoError.create (/home/yanick/.meteor/packages/npm-mongo/.2.2.33.17o8og2.hqf1++os+web.browser+web.cordova/npm/node_modules/
mongodb-core/lib/error.js:31:11)
W20171130-08:37:43.889(-5)? (STDERR)     at queryCallback (/home/yanick/.meteor/packages/npm-mongo/.2.2.33.17o8og2.hqf1++os+web.browser+web.cordova/npm/node_modules/mongodb-core/
lib/cursor.js:212:36)
W20171130-08:37:43.889(-5)? (STDERR)     at /home/yanick/.meteor/packages/npm-mongo/.2.2.33.17o8og2.hqf1++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/connection/
pool.js:469:18
W20171130-08:37:43.890(-5)? (STDERR)     at _combinedTickCallback (internal/process/next_tick.js:131:7)
W20171130-08:37:43.890(-5)? (STDERR)     at process._tickCallback (internal/process/next_tick.js:180:9)
=> Exited with code: 1
=> Meteor server restarted
=> Started your app.

=> App running at: http://localhost:3100/

Well.... crap? 🤷‍♂️

radekmie · 2017-12-09T18:29:26Z

It's still present on 1.6.1-beta.14. And yes, only during meteor test --full-app.

[[[[[ Tests ]]]]]                             

=> Started proxy.                             
=> Started MongoDB.                           
                                              
~/.meteor/packages/meteor-tool/.1.6.1-beta.14.3u350n.8b8f++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:313
            throw(ex);
            ^
MongoError: not master and slaveOk=false
    at Function.MongoError.create (~/.meteor/packages/npm-mongo/.2.2.33.1ijum74.pwfok++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/error.js:31:11)
    at queryCallback (~/.meteor/packages/npm-mongo/.2.2.33.1ijum74.pwfok++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/cursor.js:212:36)
    at ~/.meteor/packages/npm-mongo/.2.2.33.1ijum74.pwfok++os+web.browser+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:469:18
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)
=> Started your app.

=> App running at: http://localhost:3000/

jordangarside · 2018-02-25T23:07:20Z

Still have this issue with version 1.6.1 on linux.

Happens for me on startup with meteor test, but then proceeds to restart and continue.
With meteor test --once it just fails and exits.

bvanderdrift · 2018-06-20T07:46:40Z

Can confirm this problem still persists on our CircleCI server at version 1.7.0.3. Get the error around every 4 runs.

hexsprite · 2018-06-20T15:57:58Z

This is still a problem in Meteor. Shouldn't this issue be re-opened so that it gets eyes on it?

wursttheke · 2018-07-10T10:53:32Z

This is still happening for us on Circle CI (currently running on 1.6.1.3). Very annoying. It fails randomly. This issue should be reopened.

SoftwareSing · 2018-07-19T18:33:48Z

I don't know how to really fix this problem, so I just reinstall Meteor, then I can test one time.......
reinstall Meteor => test => reinstall Meteor => test => reinstall Meteor => test .....................

hexsprite · 2018-07-23T16:57:31Z

This is what I do in CI:

for i in {1..3}; do
  meteor npm run test-all && break;
done

greemin · 2018-08-02T12:34:33Z

Same problem for me in Meteor 1.7.0.3

etyp · 2018-08-03T15:10:36Z

Still an issue for us as well on Meteor 1.6.1

etyp · 2018-10-10T01:58:15Z

@hexsprite are you still experiencing this? We tried your for loop but I think it's leading to oom issues (not sure).

etyp · 2018-10-16T22:31:34Z

@abernix any suggestions on how we can help diagnose the issue? Any places to add logging, waits or anything else.

This has gotten progressively worse for us from 1.6 --> 1.7 --> 1.8 and all the hacks we've attempted have fallen short 😞

hexsprite · 2018-10-24T13:59:20Z

@etyp I can't see why it would OOM any more than a single invocation. It's just sequentially running the tests up to 3 times and exiting early if they pass.

etyp · 2018-10-24T14:04:34Z

So our solution here, which has worked well so far, is running a separate local mongodb and having Meteor use that. We haven't encountered the issue since, but hopefully we don't have to stick with it forever.

hexsprite · 2018-10-30T20:41:43Z

@etyp can you share the config? I might switch over to use that as well

etyp · 2018-10-31T17:27:25Z

@hexsprite sure. See modified version of our config.yml file below:

version: 2
jobs:
  build:
    working_directory: ~/OurApp

    resource_class: medium+

    docker:
      - image: circleci/node:latest-browsers
        environment:
          TOOL_NODE_FLAGS: --max-old-space-size=3072
          LANG: C.UTF-8
          LANGUAGE: C.UTF-8
          LC_ALL: C.UTF-8
          LC_NUMERIC: en_US.UTF-8
          METEOR_BIN_TMP_DIR: /home/circleci/build-temp/
          METEOR_BIN_TMP_FILE: meteor-bin-temp
          ARTIFACTS_PATH: /tmp/artifacts
          MOCHA_FILE: /tmp/junit/mocha/test-results.xml
      - image: redis
      - image: circleci/mongo:4-ram
        command: --port 3001

    steps:
      - checkout

      # Restoring cache
      - restore_cache:
          key: build-temp-{{ checksum ".meteor/release" }}-{{ checksum ".circleci/config.yml" }}
      - restore_cache:
          key: meteor-release-{{ checksum ".meteor/release" }}-{{ checksum ".circleci/config.yml" }}
      - restore_cache:
          key: meteor-packages-{{ checksum ".meteor/versions" }}-{{ checksum ".circleci/config.yml" }}
      - restore_cache:
          key: npm-packages-{{ checksum "package.json" }}-{{ checksum ".circleci/config.yml" }}
      - restore_cache:
          key: browser-stack-local

      # Restoring cached Meteor bin
      - run:
          name: Restoring cached Meteor bin
          command: ./.circleci/restore_cached_meteor_bin.sh

      # Installing Meteor if bin isn't found
      - run:
          name: Installing Meteor
          command: ./.circleci/install_meteor.sh

      # Installing dependencies
      - run:
          name: Installing Chrome
          command: ./.circleci/install_chrome.sh
      - run:
         shell: sudo /bin/bash -eo pipefail
         name: Install tunnel to CrossBrowserTesting
         command: sudo npm install -g cbt_tunnels; TUNNEL_NAME=`date | md5sum | grep -o "^\S*"`
      - run:
          name: Install npm packages
          command: meteor npm install

      - run:
          name: Creating artifacts dir
          command: mkdir /tmp/artifacts
      - run:
          name: Creating test result dir
          command: mkdir -p /tmp/junit/mocha

      # Run API tests		
      - run:
           name: Running API tests
           command: MONGO_URL='mongodb://localhost:3001/meteor' npm run test-api
           no_output_timeout: 45m

      # Save Meteor bin to cache
      - run:
          name: Saving Meteor bin to build cache
          command: ./.circleci/cache_meteor_bin.sh

      # Save other cache
      - save_cache:
          key: build-temp-{{ checksum ".meteor/release" }}-{{ checksum ".circleci/config.yml" }}
          paths:
            - ~/build-temp
      - save_cache:
          key: meteor-release-{{ checksum ".meteor/release" }}-{{ checksum ".circleci/config.yml" }}
          paths:
            - ~/.meteor
      - save_cache:
          key: meteor-packages-{{ checksum ".meteor/versions" }}-{{ checksum ".circleci/config.yml" }}
          paths:
            - .meteor/local/build
            - .meteor/local/bundler-cache
            - .meteor/local/isopacks
            - .meteor/local/plugin-cache
      - save_cache:
          key: npm-packages-{{ checksum "package.json" }}-{{ checksum ".circleci/config.yml" }}
          paths:
            - ./node_modules/
            - ~/.npm/

The key things to call out are:

Using CircleCI mongo image:

      - image: circleci/mongo:4-ram
        command: --port 3001

Prefixing any meteor command to include the MONGO_URL so it doesn't start its own mongo:

      - run:
           name: Running API tests
           command: MONGO_URL='mongodb://localhost:3001/meteor' npm run test-api

Alternatively, if you want to just run meteor as-is (like we do elsewhere for e2e tests), just make sure to prefix the meteor run command with the same thing, like:

MONGO_URL='mongodb://localhost:3001/meteor' meteor run --port 3000 --settings my-settings.json

Hope that helps. We haven't experienced this issue at all since making the change.

mariushop · 2019-02-07T15:34:47Z

Still having this problem on 1.8, February 2019

Using the `isMaster` command instead of checking the replica set member state is more reliable because a node can be a primary without being writable. Fixes #10381 and #9026.

…e problem

* trying update based on https://unix.stackexchange.com/questions/508724/failed-to-fetch-jessie-backports-repository * added apt-transport-https based on https://askubuntu.com/questions/165676/how-do-i-fix-a-e-the-method-driver-usr-lib-apt-methods-http-could-not-be-foun * alternative solution to https://unix.stackexchange.com/questions/508724/failed-to-fetch-jessie-backports-repository * trying feedback in meteor/meteor#9026 (comment) to fix mongo not slave problem * changing port to 3001 since that's what circleci uses for mongo docker image... lets see if that works * fixed typo ordering of arguments

* copied some caching techniques from meteor/meteor#9026 * fix the meteor install from breaking * moved order to not break Meteor build

hwillson added the Project:Mongo Driver label Sep 15, 2017

abernix added Type:Bug confirmed We want to fix or implement it Impact:few labels Sep 19, 2017

znerol mentioned this issue Sep 20, 2017

Tests failing on Travis-CI after update to 1.5.2 Openki/Openki#942

Closed

abernix added the review label Sep 20, 2017

abernix mentioned this issue Sep 20, 2017

When starting mongod, yield until the heartbeat has pulsed after election. #9119

Merged

benjamn closed this as completed in #9119 Sep 20, 2017

This comment has been minimized.

Sign in to view

klaussner mentioned this issue Mar 19, 2019

Wait until primary node is writable #10500

Merged

This comment has been minimized.

Sign in to view

noahsw added a commit to winsleague/winsleague that referenced this issue Sep 4, 2019

trying feedback in meteor/meteor#9026 (comment) to fix mongo not slav…

a7fbd3f

…e problem

noahsw added a commit to winsleague/winsleague that referenced this issue Sep 8, 2019

copied some caching techniques from meteor/meteor#9026

cc78aa0

noahsw added a commit to winsleague/winsleague that referenced this issue Sep 8, 2019

Feature/better caching (#544)

af9d460

* copied some caching techniques from meteor/meteor#9026 * fix the meteor install from breaking * moved order to not break Meteor build

[1.6b23] tests fails on startup: MongoError: not master and slaveOk=false #9026

[1.6b23] tests fails on startup: MongoError: not master and slaveOk=false #9026

Comments

hexsprite commented Aug 18, 2017 • edited Loading

abernix commented Aug 23, 2017

hexsprite commented Aug 31, 2017

hexsprite commented Aug 31, 2017

hexsprite commented Aug 31, 2017 • edited Loading

hexsprite commented Aug 31, 2017

hexsprite commented Sep 1, 2017

hexsprite commented Sep 1, 2017 • edited Loading

abernix commented Sep 14, 2017

timbotnik commented Sep 14, 2017

hexsprite commented Sep 15, 2017

abernix commented Sep 15, 2017

remotealex commented Sep 19, 2017

abernix commented Sep 19, 2017 • edited Loading

remotealex commented Sep 19, 2017

abernix commented Sep 19, 2017

remotealex commented Sep 19, 2017

abernix commented Sep 20, 2017 • edited Loading

remotealex commented Sep 20, 2017

abernix commented Sep 20, 2017

znerol commented Sep 20, 2017

yanickrochon commented Nov 27, 2017

yanickrochon commented Nov 27, 2017

hexsprite commented Nov 28, 2017

yanickrochon commented Nov 28, 2017

yanickrochon commented Nov 30, 2017 • edited Loading

yanickrochon commented Nov 30, 2017 • edited Loading

radekmie commented Dec 9, 2017

jordangarside commented Feb 25, 2018 • edited Loading

bvanderdrift commented Jun 20, 2018

hexsprite commented Jun 20, 2018

wursttheke commented Jul 10, 2018

SoftwareSing commented Jul 19, 2018

hexsprite commented Jul 23, 2018

greemin commented Aug 2, 2018

etyp commented Aug 3, 2018

etyp commented Oct 10, 2018

etyp commented Oct 16, 2018

hexsprite commented Oct 24, 2018

etyp commented Oct 24, 2018

hexsprite commented Oct 30, 2018

etyp commented Oct 31, 2018

mariushop commented Feb 7, 2019

This comment has been minimized.

This comment has been minimized.

hexsprite commented Aug 18, 2017 •

edited

Loading

hexsprite commented Aug 31, 2017 •

edited

Loading

hexsprite commented Sep 1, 2017 •

edited

Loading

abernix commented Sep 19, 2017 •

edited

Loading

abernix commented Sep 20, 2017 •

edited

Loading

yanickrochon commented Nov 30, 2017 •

edited

Loading

yanickrochon commented Nov 30, 2017 •

edited

Loading

jordangarside commented Feb 25, 2018 •

edited

Loading