Client experienced a timeout - validate_lab_change_dbpath

This is what I’ve done for the lab

  • vagrant ssh

  • Created a config file in /shared/mongodb.conf
    storage:
    dbPath: “/var/mongodb/db”
    net:
    bindIp: 127.0.0.1,192.168.103.100
    port: 27000

  • Called mongod -f /shared/mongodb.conf
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] MongoDB starting : pid=2826 port=27000 dbpath=/var/mongodb/db 64-bit host=m103
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] db version v3.6.16
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] git version: 204ab367a130a4fd2db1c54b02cd6a86e4e07f56
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] allocator: tcmalloc
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] modules: enterprise
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] build environment:
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] distmod: ubuntu1404
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] distarch: x86_64
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] target_arch: x86_64
    2019-12-25T04:13:18.119+0000 I CONTROL [initandlisten] options: { config: “/shared/mongodb.conf”, net: { bindIp: “127.0.0.1,192.168.103.100”, port: 27000 }, storage: { dbPath: “/var/mongodb/db” } }
    2019-12-25T04:13:18.119+0000 I - [initandlisten] Detected data files in /var/mongodb/db created by the ‘wiredTiger’ storage engine, so setting the active storage engine to ‘wiredTiger’.
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten]
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=488M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),compatibility=(release=“3.0”,require_max=“3.0”),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
    2019-12-25T04:13:18.721+0000 I STORAGE [initandlisten] WiredTiger message [1577247198:721588][2826:0x7f2fcc509ac0], txn-recover: Main recovery loop: starting at 1/36864
    2019-12-25T04:13:18.789+0000 I STORAGE [initandlisten] WiredTiger message [1577247198:789376][2826:0x7f2fcc509ac0], txn-recover: Recovering log 1 through 2
    2019-12-25T04:13:18.826+0000 I STORAGE [initandlisten] WiredTiger message [1577247198:826194][2826:0x7f2fcc509ac0], txn-recover: Recovering log 2 through 2
    2019-12-25T04:13:18.862+0000 I STORAGE [initandlisten] WiredTiger message [1577247198:862444][2826:0x7f2fcc509ac0], txn-recover: Set global recovery timestamp: 0
    2019-12-25T04:13:18.877+0000 I CONTROL [initandlisten]
    2019-12-25T04:13:18.877+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
    2019-12-25T04:13:18.878+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
    2019-12-25T04:13:18.878+0000 I CONTROL [initandlisten]
    2019-12-25T04:13:18.881+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory ‘/var/mongodb/db/diagnostic.data’
    2019-12-25T04:13:18.881+0000 I NETWORK [initandlisten] listening via socket bound to 127.0.0.1
    2019-12-25T04:13:18.882+0000 I NETWORK [initandlisten] listening via socket bound to 192.168.103.100
    2019-12-25T04:13:18.883+0000 I NETWORK [initandlisten] listening via socket bound to /tmp/mongodb-27000.sock
    2019-12-25T04:13:18.883+0000 I NETWORK [initandlisten] waiting for connections on port 27000

  • Called mongo --port 27000
    MongoDB shell version v3.6.16
    connecting to: mongodb://127.0.0.1:27000/?gssapiServiceName=mongodb
    Implicit session: session { “id” : UUID(“09338cc1-5df9-46d2-a392-612008f0e0c8”) }
    MongoDB server version: 3.6.16
    Server has startup warnings:
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten]
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
    2019-12-25T04:13:18.119+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
    2019-12-25T04:13:18.877+0000 I CONTROL [initandlisten]
    2019-12-25T04:13:18.877+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
    2019-12-25T04:13:18.878+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
    2019-12-25T04:13:18.878+0000 I CONTROL [initandlisten]
    MongoDB Enterprise >

  • Then I quit the mongo shell and return to the MongoD process, and try to run the validate_lab_change_dbpath command, and I get the “client experienced a timeout error…”

Some things I’ve done to troubleshoot

  • the port is specified as 27000 in the config file
  • the IP addresses seems correct
  • I created a user using the command from the first lab to paste in the mongo shell
  • when I call: ps -ef | grep mongod

vagrant 2964 2925 5 04:28 pts/3 00:00:00 mongod -f /shared/ mongod b.conf
vagrant 2995 2581 0 04:29 pts/1 00:00:00 grep --color=auto mongod

Any ideas?

The output of ps seems to indicated some typos in starting *mongod. It looks like you have a misplaced spaced right in the middle of the configuration file name. However the logs seems to indicate that mongod was started correctly. May be the good mongod was stopped before running the validation script.

That was a formatting error when I pasted the output, doesn’t seem to be the issue…

It just confuses me because mongod and the mongo shell starts up perfectly, but the validate command just keeps returning the client timeout error

I don’t remember exact lab description but please double check the lab requirements
Did you use security param authorization?
Are you able to login with the user you created?

I was missing the authorization parameter! Thank you for the reminder, it’s just that my previous labs worked without authorization so I assumed it wasn’t necessary.

Closing the thread as the issue has been resolved.