Mongo: New 4.0.21 Image Fails to Start When Using Non-YAML Config Files

Created on 5 Dec 2020  路  4Comments  路  Source: docker-library/mongo

We are running mongo on a docker swarm, using old non-yaml style of config files. Our configs were working normally with version 4.0.20, but after upgrading to the latest 4.0.21 pushed around 15 hours ago, mongo no longer started. The error log is as follow:

error: unexpected "js-yaml.js" output while parsing config:
2020-12-05T15:54:50.516+0000 E QUERY    [js] YAMLException: end of the stream or a document separator is expected at line 7, column 1:
    logpath=/data/log/mongodb/mongod ...
    ^ :
YAMLException@/js-yaml.js:952:19
generateError@/js-yaml.js:1144:1
throwError@/js-yaml.js:1150:9
readDocument@/js-yaml.js:2516:5
loadDocuments@/js-yaml.js:2552:5
load@/js-yaml.js:2573:19
@(shell eval):1:32

Our config file is simple, and looks like this:

# mongodb.conf

# Where to store the data.
dbpath=/data/mongodb

#where to log
logpath=/data/log/mongodb/mongodb.log

logappend=true

#bind_ip = 127.0.0.1
bind_ip = 0.0.0.0
#port = 27017

# Enable journaling, http://www.mongodb.org/display/DOCS/Journaling
journal=true

# Enables periodic logging of CPU utilization and I/O wait
#cpu = true

# Turn on/off security.  Off is currently the default
#noauth = true
auth = true

# [...] everything beyond this point is commented out

The relevant part of our docker-compose file looks like:

  mongo-db:
    image: mongo:4.0.21
    ports:
      - "27018:27017"
    configs:
      - source: mongo
        target: /etc/mongod.conf
    volumes:
      - "/data/mongo-dev:/data/"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1000M                                                                                                                                                                 
    command: --config /etc/mongod.conf

Simply rolling back to 4.0.20 is enough for the mongo container to boot and work again. It is probable that this issue is related to the change that happened in https://github.com/docker-library/mongo/pull/442

Most helpful comment

@tianon I have downloaded the patch at https://github.com/docker-library/mongo/pull/447, applied it to master (which is currently at https://github.com/docker-library/mongo/tree/8a27bbbc4ef1ef303668e44a7b658933bb22672d), and built the 4.0 image locally. I can confirm the patch fixes the issue; the image appears to be working normally with the old init-style configs we're using, and it shows the new warning as expected.

Thank you for your efforts, everyone :)

All 4 comments

Oh, just noticed that when running on 4.0.20, in the logs we get:

parse error: Invalid numeric literal at line 1, column 14
parse error: Invalid numeric literal at line 1, column 14

But despite that, the mongo database works normally, and applies the correct configurations described in the config file (and has worked normally with this config for almost two years).

Oh neat, we didn't realize that MongoDB still supported the ini format that was replaced back in 2.6 with the yaml version. We've never parsed the ini version, so as you may have discovered, you would have had to do some of the provided entrypoint functionality (like bind_ip). It looks like it is now erroring on line 356 (since we switched the _parse_config to exit on bad yaml, rather than returning):

https://github.com/docker-library/mongo/blob/8a27bbbc4ef1ef303668e44a7b658933bb22672d/docker-entrypoint.sh#L352-L362

I think we can adjust the parse function to ignore (and warn) on ini formatted files.

@mohammad-matini if you could test https://github.com/docker-library/mongo/pull/447, that'd be appreciated :+1:

@tianon I have downloaded the patch at https://github.com/docker-library/mongo/pull/447, applied it to master (which is currently at https://github.com/docker-library/mongo/tree/8a27bbbc4ef1ef303668e44a7b658933bb22672d), and built the 4.0 image locally. I can confirm the patch fixes the issue; the image appears to be working normally with the old init-style configs we're using, and it shows the new warning as expected.

Thank you for your efforts, everyone :)

Was this page helpful?
0 / 5 - 0 ratings