-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
Minor - P4
-
None
-
Affects Version/s: 3.0.15, 4.0.0
-
Component/s: Admin
-
None
-
Service Arch
-
ALL
I discovered what may be a bug in the server's format detection for configuration files (between legacy 2.4 format and YAML, which was introduced in 2.6). Consider:
vagrant@vagrant-ubuntu-trusty-64:~$ /home/vagrant/3.0/usr/bin/mongod --config /home/vagrant/30.conf --port 2700 Error parsing YAML config file: yaml-cpp: error at line 8, column 18: illegal map value try '/home/vagrant/3.0/usr/bin/mongod --help' for more information vagrant@vagrant-ubuntu-trusty-64:~$ cat 30.conf dbpath=/tmp/standalone-30/ nssize=1 journal=true logappend=true logpath=/tmp/standalone-30/mongod.log smallfiles=true oplogSize=100 bind_ip=0.0.0.0,:: ipv6=true setParameter = enableTestCommands=1 vagrant@vagrant-ubuntu-trusty-64:~$
Since I was working with a 3.0 server, I was using the bind_ip equivalent for bind_ip_all (introduced in 3.6).
This is a configuration file produced by Mongo Orchestration. Since MO supports 2.4, it generates config files in the legacy format.
Here, it looks like the the trailing colon on line 8 caused mongod to assume it was loading a YAML config file.
Values in legacy 2.4 config files cannot be quoted. I attempted to wrap 0.0.0.0,:: in quotes and observed the following startup error:
2018-06-20T17:28:56.902+0000 I CONTROL [initandlisten] options: { config: "/home/vagrant/30.conf", net: { bindIp: ""0.0.0.0,::"", ipv6: true, port: 2700 }, replication: { oplogSizeMB: 100 }, setParameter: { enableTestCommands: "1" }, storage: { dbPath: "/tmp/standalone-30/", journal: { enabled: true }, mmapv1: { nsSize: 1, smallFiles: true } }, systemLog: { destination: "file", logAppend: true, path: "/tmp/standalone-30/mongod.log" } }
2018-06-20T17:28:56.969+0000 I NETWORK [initandlisten] getaddrinfo(""0.0.0.0") failed: Name or service not known
2018-06-20T17:28:56.971+0000 I NETWORK [initandlisten] getaddrinfo("::"") failed: Name or service not known
I was able to work around this issue by swapping the order of the IP addresses to ::,0.0.0.0.
Assuming this is a bug, I certainly don't expect that a fix would be backported to 3.0 (or 2.6). It may be prudent to simply change the order of the IP addresses in our documentation, which should minimize the chance of other users coming across this.