Since I’m developing on Windows 10 and MDG hasn’t released a 1.6.1.x patch version to fix the Windows symlink problem, I upgraded to 1.7 rc11 (the latest release candidate). After adding a couple of missing packages and rebuilding my db everything seemed to work ok. But now every few hours mongo exits with code 3 (not master and slaveOk=false) and restarts. According to the Mongo docs the error seems to relate to trying to read from a specific mongo replica set rather than from the master, but I have no replica sets. I can’t tell if this is related to Meteor 1.7 or the 3.6 version of Mongo. Anyone else seeing this or have a suggestion as to how to fix?
1 Like
If you are running meteor in development you do have replica sets, as Meteor sets these up for you, in order that oplog tailing can work.
However, as to your actual problem, I’ve not seen this. I’ll try it myself in Windows to see if I can replicate it.
1 Like
I recently had this issue with Meteor 1.6 in production. Oddly, it broke the entire data layer, and was fixed by a manual restart.
1 Like
Ah, knowing that I do have replica sets makes a bit more sense. The server stack trace that follows the crash occasional is ECONNREFUSED, which makes sense since Mongo may not have come up fully when the query was being made, but more often than not I get some flavor of this:
I20180528-19:58:13.001(-7)? Exception while polling query {"collectionName":"MeteorToys.Impersonate","selector":{},"options":{"transform":null,"limit":15}} { MongoError: not master and slaveOk=false
Maybe MeteorToys isn’t compatible with 1.7? I’ll try removing it and see if the crashes stop (meteortoys is included by msavin:mongol, which I can probably live without.)
@robfallows, I doubt you could reproduce it. It appears to be “random” as my app ran fine
overnight, but crashed 3 times yesterday.
@msavin, the crashes don’t seem to have an effect on the functioning of the app once Mongo restarts, but that may simply be that this is in dev mode and there is no load on the app. Manual restarts don’t make any difference.
It’s hard to find in the meteor source, but if they’re using Mongo 3.6, they’re going to discover that it has a colossal number of problems on Windows, including almost certainly yours.
To address your issues, I’d recommend installing MongoDB 3.6 series from an MSI and using MONGO_URL to connect to a locally-running, administrative privileges elevated mongod started as a replica set.
@doctorpangloss, 1.7-rc11 uses Mongo 3.6.4. I’m not having any problems with Mongo other than this specific error. I removed the mongol package (which removes meteortoys package) and have made it to the 24 hour mark with no crashes. Once I hit the 48 hour mark tomorrow, I’m going to put mongol back in and see what happens. But at this point, I’m leaning toward a compatibility problem with meteortoys and the meteor 1.7 stack. The meteortoys website only claims 1.5 compatibility, so I wouldn’t be surprised if there is a problem with 1.7 given all of the changes since 1.5.
Well, the problem is not related to MeteorToys.
Windows, as is it’s wont, decided to restart itself, and the problem started happening again. Sometimes node.js provides a stack trace, sometimes node doesn’t even seem to notice. The problem may be a Windows 10 MongoDB issue, but my Python apps that also access the meteor DB don’t seem to be experiencing the problem. Any suggestions as to how to debug the issue? I’m happy to add whatever monitoring or test code anyone cares to suggest. I’m loath to push the meteor 1.7rc to my Linux server since my app there is being used by my testers. At this point, I’m going to ignore the problem and wait to push my app to Linux until 1.7 is actually released.
I just noticed that Mongo exited twice while I was typing this. Since no one was accessing my app, the exits/crashes seem to happen at random intervals.
I also faced this problem today when running meteor test. Here’s the full output I got:
[[[[[ Tests ]]]]]
=> Started proxy.
=> A patch (Meteor 1.7.0.4) for your current release is available!
Update this project now with 'meteor update --patch'.
=> Started MongoDB.
/Users/simon/.meteor/packages/meteor-tool/.1.7.0_3.3wbwpi.u6uua++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:313
throw(ex);
^
MongoError: not master and slaveOk=false
at queryCallback (/Users/simon/.meteor/packages/npm-mongo/.3.0.7.iikbq7.drrf++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/cursor.js:244:25)
at /Users/simon/.meteor/packages/npm-mongo/.3.0.7.iikbq7.drrf++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:544:18
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
=> Started your app.
=> App running at: http://localhost:3100/
npm ERR! Test failed. See above for more details.
I’m using Meteor 1.7.0.3 and (as you see) meteor also spins up the database.
Any other info I can give you? I also had this once on our hosted development environment but I have not seen it otherwise. It seems to be occasional, so I guess it’s very hard to reproduce. I would give a hint on a race-condition when spinning up the replica set - could this be true?
1 Like
Most likely, Meteor Toys collections are showing up because they load the rest of your code. IIRC, the code in packages executes prior to the code in ./server
Removing MeteorToys and mongol had no effect on the problem. I still see the error several times per day. Other than being an annoyance, the error doesn’t seem to cause any user visible problems.
Any luck resolving this one? It’s currently killing our CI despite several hacky workarounds 
No luck resolving this. I stripped out as much code (both mine and 3rd party) from my app while still leaving it able to query the database and the problem remained. Stopping the Python apps that also access the MongoDB instance also did nothing. I was hoping that someone smarter than me (or at least with more free time) would figure this out.
One thing that I didn’t try (since it wasn’t available yet) is to try against a MongoDB 4 server. Another possible way to find the issue would be to roll my Meteor back to 1.6 and compare network traces against 1.7.
= Ron
I was having the same problem and doing a meteor reset solved it for me
— update —
I spoke to soon. The reset seemed to fix it, but after a minute or so the problem came right back.
I’m experiencing a similar problem, but this time on “clean” Ubuntu 14.04.5 LTS instance on Travis CI. I’m still investigating, but it appears that invocation of “meteor test” causes the problem intermittently . Below is a stack trace. It feels like the meteor application may be starting before the Mongo is ready. Could this just be a timing/race issue?
$ meteor test --once --driver-package dispatch:mocha-phantomjs
[[[[[ Tests ]]]]]
=> Started proxy.
=> A patch (Meteor 1.8.0.2) for your current release is available!
Update this project now with 'meteor update --patch'.
=> Started MongoDB.
W20190112-16:47:38.937(0)? (STDERR) /home/travis/.meteor/packages/meteor-tool/.1.8.0_1.cl3wcy.5t0hj++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:313
W20190112-16:47:38.976(0)? (STDERR) throw(ex);
W20190112-16:47:38.976(0)? (STDERR) ^
W20190112-16:47:38.977(0)? (STDERR)
W20190112-16:47:38.977(0)? (STDERR) MongoError: not master and slaveOk=false
W20190112-16:47:38.977(0)? (STDERR) at queryCallback (/home/travis/.meteor/packages/npm-mongo/.3.1.1.v3rpzk.m5kk8++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/cursor.js:248:25)
W20190112-16:47:38.977(0)? (STDERR) at /home/travis/.meteor/packages/npm-mongo/.3.1.1.v3rpzk.m5kk8++os+web.browser+web.browser.legacy+web.cordova/npm/node_modules/mongodb-core/lib/connection/pool.js:532:18
W20190112-16:47:38.978(0)? (STDERR) at _combinedTickCallback (internal/process/next_tick.js:131:7)
W20190112-16:47:38.978(0)? (STDERR) at process._tickDomainCallback (internal/process/next_tick.js:218:9)
=> Started your app.
=> App running at: http://localhost:3000/
The command "meteor test --once --driver-package dispatch:mocha-phantomjs" exited with 1.
I’m also experiencing this in our Galaxy production environment. We’re running Meteor 1.12.2 and Mongo 4.2.21. Often causes the container to crash.
Exception while polling query {"collectionName":"users","selector":{"_id":"---hidden---","services.resume.loginTokens.hashedToken":"---hidden---"},"options":{"transform":null,"fields":{"_id":1}}} MongoError: not master and slaveOk=false
Usually get a few variations of this query exception at the same moment with different users but seems to happen at random times.