mongod runs with command but not with config file

Question

I am trying to start mongod with a config file on MongoDB 3.2 on Ubuntu 14.04. I can launch mongod by issuing the command myself, but I can't get it to work with the config file.

Here's the command I'm issuing:

sudo mongod --replSet rs0 --logpath /var/log/mongodb/mongod.log --dbpath /data/db --storageEngine wiredTiger --fork

When I run this command, I can then run mongo to enter the mongo shell and successfully use the database.

I don't see a difference between the command I'm issuing and the config file, which I call with sudo mongod --config /etc/mongod.conf. When I run this, and try a command in the same mongo shell I had successfully used for the prior query, I get

2017-01-31T10:55:44.899-0800 E QUERY    [thread1] Error: error: { "ok" : 0, "errmsg" : "not master and slaveOk=false", "code" : 13435 } :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DBCommandCursor@src/mongo/shell/query.js:689:1
DBQuery.prototype._exec@src/mongo/shell/query.js:118:28
DBQuery.prototype.hasNext@src/mongo/shell/query.js:276:5
DBCollection.prototype.findOne@src/mongo/shell/collection.js:289:10
@(shell):1:1

and here is my /etc/mongod.conf. How are these different?:

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
  dbPath: "/data/db"
  journal:
    enabled: true
  engine: "wiredTiger"
#  mmapv1:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: "/var/log/mongodb/mongod.log"

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1


processManagement:
  fork: true

#security:

#operationProfiling:

replication:
  replSetName: rs0
#  oplogSizeMB: 1024

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

Answer 1

That error message "not master and slaveOk=false" is what you get when you try to query on a secondary server. If you're getting that message, that implies that:

1. The server has successfully started
2. The server has successfully joined the replica set
3. A different server is currently Primary

You should be able to check that by running rs.status() in the shell (assuming your user account has replicaset administration privileges).

If you want to run a query on this server to confirm that it is working (even though it is currently a secondary), you can use the rs.slaveOk call.