Details
-
Bug
-
Resolution: Won't Fix
-
Minor - P4
-
None
-
3.0.15, 4.0.0
-
None
-
Service Arch
-
ALL
Description
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.
Attachments
Issue Links
- related to
-
DOCS-11822 Reorder addresses in bind_ip example for bind_ip_all equivalent
-
- Closed
-