MongoDB.live, free & fully virtual. June 9th - 10th. Register Now MongoDB.live, free & fully virtual. June 9th - 10th. Register Now

MongoDB won't start as a windows service, but will start at the command line

Hi
I have been using MongoDB Community edition (version mongodb-win32-x86_64-2012plus-4.2.5-signed) on my PC until yesterday, running Windows 10. Not sure if this is relevant, but for background I am accessing the same DB from a laptop (same versions of MongoDB and Windows10), not at the same time (!), so that I can do development work at home or when away. I have the MongoDB files set up in a folder that is mirrored across devices using sync.com (similar to Dropbox). This has worked all worked fine until yesterday.

Yesterday mongoDB would not start as a service on my main PC (note it continues to work fine on my laptop - the service starts and I can access the db no problem). I have tried various options suggested on the internet including --repair, trying to give admin permissions to everything (although think this is unnecessary because it worked without special permissions before and from what I can see most recommendations about this are the unix/linux installs) and finally I have done a full uninstall and clean install. I am at a point where the Windows service will not start, nor will it work if I run it from the command line… unless I remove the --server option and then it works fine.

So, if I run the following at the command line the service doesn’t start (this is copied and pasted from the Windows services “path to executable”):
“C:\Program Files\MongoDB\Server\4.2\bin\mongod.exe” --config “C:\Program Files\MongoDB\Server\4.2\bin\mongod.cfg” --service

However, if I run the following at the command line then it works fine and I am able to connect using Compass/run my app:
“C:\Program Files\MongoDB\Server\4.2\bin\mongod.exe” --config “C:\Program Files\MongoDB\Server\4.2\bin\mongod.cfg”

Note this is running in the command prompt without admin rights in both cases, which I think suggests this isn’t a rights issue(?)

The log file for the failed start isn’t very informative (to me at least, but then I am completely new to this!) I have included the log below that includes both the failed start using the --server option and then a successful run with the --server option removed. Note I have inserted a blank line between the two runs just for clarity.

2020-03-31T08:53:51.977+0100 I  CONTROL  [main] ***** SERVER RESTARTED *****
2020-03-31T08:53:51.982+0100 I  CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2020-03-31T08:53:52.850+0100 W  ASIO     [main] No TransportLayer configured during NetworkInterface startup
2020-03-31T08:53:52.851+0100 I  CONTROL  [main] Trying to start Windows service 'MongoDB'

2020-03-31T08:54:12.058+0100 I  CONTROL  [main] ***** SERVER RESTARTED *****
2020-03-31T08:54:12.889+0100 I  CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2020-03-31T08:54:12.894+0100 W  ASIO     [main] No TransportLayer configured during NetworkInterface startup
2020-03-31T08:54:12.895+0100 I  CONTROL  [initandlisten] MongoDB starting : pid=6892 port=27017 dbpath=C:\Users\Bob\Sync\Programming\MongoDB\data 64-bit host=Music-PC
2020-03-31T08:54:12.895+0100 I  CONTROL  [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2020-03-31T08:54:12.895+0100 I  CONTROL  [initandlisten] db version v4.2.5
2020-03-31T08:54:12.895+0100 I  CONTROL  [initandlisten] git version: 2261279b51ea13df08ae708ff278f0679c59dc32
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten] allocator: tcmalloc
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten] modules: none
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten] build environment:
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten]     distmod: 2012plus
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten]     distarch: x86_64
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten]     target_arch: x86_64
2020-03-31T08:54:12.896+0100 I  CONTROL  [initandlisten] options: { config: "C:\Program Files\MongoDB\Server\4.2\bin\mongod.cfg", net: { bindIp: "127.0.0.1", port: 27017 }, storage: { dbPath: "C:\Users\Bob\Sync\Programming\MongoDB\data", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "C:\Users\Bob\Sync\Programming\MongoDB\log\mongod.log" } }
2020-03-31T08:54:12.900+0100 I  STORAGE  [initandlisten] Detected data files in C:\Users\Bob\Sync\Programming\MongoDB\data created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2020-03-31T08:54:12.901+0100 I  STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=3582M,cache_overflow=(file_max=0M),session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress],
2020-03-31T08:54:13.006+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:6456][6892:140724896882256], txn-recover: Recovering log 17 through 18
2020-03-31T08:54:13.164+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:164656][6892:140724896882256], txn-recover: Recovering log 18 through 18
2020-03-31T08:54:13.362+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:361919][6892:140724896882256], txn-recover: Main recovery loop: starting at 17/7808 to 18/256
2020-03-31T08:54:13.654+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:653905][6892:140724896882256], txn-recover: Recovering log 17 through 18
2020-03-31T08:54:13.812+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:812105][6892:140724896882256], txn-recover: Recovering log 18 through 18
2020-03-31T08:54:13.959+0100 I  STORAGE  [initandlisten] WiredTiger message [1585641253:958585][6892:140724896882256], txn-recover: Set global recovery timestamp: (0, 0)
2020-03-31T08:54:13.992+0100 I  RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2020-03-31T08:54:14.001+0100 I  STORAGE  [initandlisten] Timestamp monitor starting
2020-03-31T08:54:14.012+0100 I  CONTROL  [initandlisten] 
2020-03-31T08:54:14.013+0100 I  CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-03-31T08:54:14.013+0100 I  CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2020-03-31T08:54:14.013+0100 I  CONTROL  [initandlisten] 
2020-03-31T08:54:14.023+0100 I  SHARDING [initandlisten] Marking collection local.system.replset as collection version: <unsharded>
2020-03-31T08:54:14.027+0100 I  STORAGE  [initandlisten] Flow Control is enabled on this deployment.
2020-03-31T08:54:14.027+0100 I  SHARDING [initandlisten] Marking collection admin.system.roles as collection version: <unsharded>
2020-03-31T08:54:14.027+0100 I  SHARDING [initandlisten] Marking collection admin.system.version as collection version: <unsharded>
2020-03-31T08:54:14.031+0100 I  SHARDING [initandlisten] Marking collection local.startup_log as collection version: <unsharded>
2020-03-31T08:54:14.501+0100 I  FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory 'C:/Users/Bob/Sync/Programming/MongoDB/data/diagnostic.data'
2020-03-31T08:54:14.503+0100 I  SHARDING [LogicalSessionCacheRefresh] Marking collection config.system.sessions as collection version: <unsharded>
2020-03-31T08:54:14.504+0100 I  NETWORK  [listener] Listening on 127.0.0.1
2020-03-31T08:54:14.504+0100 I  SHARDING [LogicalSessionCacheReap] Marking collection config.transactions as collection version: <unsharded>
2020-03-31T08:54:14.504+0100 I  NETWORK  [listener] waiting for connections on port 27017
2020-03-31T08:54:15.005+0100 I  SHARDING [ftdc] Marking collection local.oplog.rs as collection version: <unsharded>
2020-03-31T08:55:47.470+0100 I  CONTROL  [thread1] Ctrl-C signal
2020-03-31T08:55:47.470+0100 I  CONTROL  [consoleTerminate] got CTRL_C_EVENT, will terminate after current cmd ends
2020-03-31T08:55:47.471+0100 I  NETWORK  [consoleTerminate] shutdown: going to close listening sockets...
2020-03-31T08:55:47.472+0100 I  -        [consoleTerminate] Stopping further Flow Control ticket acquisitions.
2020-03-31T08:55:47.472+0100 I  CONTROL  [consoleTerminate] Shutting down free monitoring
2020-03-31T08:55:47.473+0100 I  FTDC     [consoleTerminate] Shutting down full-time diagnostic data capture
2020-03-31T08:55:47.477+0100 I  STORAGE  [consoleTerminate] Deregistering all the collections
2020-03-31T08:55:47.477+0100 I  STORAGE  [consoleTerminate] Timestamp monitor shutting down
2020-03-31T08:55:47.477+0100 I  STORAGE  [consoleTerminate] WiredTigerKVEngine shutting down
2020-03-31T08:55:47.477+0100 I  STORAGE  [consoleTerminate] Shutting down session sweeper thread
2020-03-31T08:55:47.478+0100 I  STORAGE  [consoleTerminate] Finished shutting down session sweeper thread
2020-03-31T08:55:47.478+0100 I  STORAGE  [consoleTerminate] Shutting down journal flusher thread
2020-03-31T08:55:47.577+0100 I  STORAGE  [consoleTerminate] Finished shutting down journal flusher thread
2020-03-31T08:55:47.577+0100 I  STORAGE  [consoleTerminate] Shutting down checkpoint thread
2020-03-31T08:55:47.577+0100 I  STORAGE  [consoleTerminate] Finished shutting down checkpoint thread
2020-03-31T08:55:47.698+0100 I  STORAGE  [consoleTerminate] shutdown: removing fs lock...
2020-03-31T08:55:47.698+0100 I  CONTROL  [consoleTerminate] now exiting
2020-03-31T08:55:47.699+0100 I  CONTROL  [consoleTerminate] shutting down with code:12

And finally, if I start the service via the Windows Services app I get error 1053 as per the screenshot below. If I look in the Windows Event Viewer (Windows Logs\System) there are two entries for this. One with the message below and the second says, “A timeout was reached (30000 milliseconds) while waiting for the MongoDB Server service to connect.” (although it takes less than a couple of seconds to fail, not the 30 seconds this suggests).

mongodb error1053

Does anyone have any suggestions as to why this is happening and how I can fix it?

I don’t know what the root cause is, but I appear to have fixed the problem.

I had set the database service to startup using the NetworkService account in Windows, which I think was the default as part of the installation process (I wouldn’t swear to it, but I don’t know enough about it to change the option). I have now changed this to use the Local System account option and the service now starts and works without any problems. I have other services running as the NetworkService user to not sure why this is an issue.

Path to change things:
Press Cmd+R keys to bring up start menu
Type services and run the app
Locate MongoDB Server, right-click and select Properties
Access LogOn tab
Select Local System account radio button
Select OK

Job done. :slight_smile:

I don’t know what problems this might cause me later, but I’ll deal with that when I get to it. :wink: