Windows service, .lock, non local db

[ogoletti]

Hi,

I'm issuing a problem right now. If I start mongod on a disk available
throuogh the network. Then when I shutdown/restart the computer, the
service is no more able to connect because of the lock file. If I do
the same with a local db, everything is going well. I think the
connection with the db is closed before mongo is shutdown =>
mongod.lock remains and with the service, no more possibility to
connect.

My env: win7 64bit mongo 2.0.3.

Thanks for any help

[Barrie]

Are you using NFS? Can you please provide more detail on what exactly you tried that didn't work, the output you got, and the appropriate logs? It will be much easier to solve your issue with this information.

[ogoletti]

Hi,

1) I launch mongo with the database local with
D:\mongodb-win32-x86_64-2.0.3\bin\mongod.exe --install --logpath=C:\%PATH_TO_LOG%\Mongo.log --logappend --dbpath="D:\%PATH_TO_DB%" --auth
2) I start the service
3) I reboot

=> no problem

But if I try the same with the db being on an external disk reached through a windows network (replace --dbpath="\\%NETWORK_DISK%\%PATH_TO_DB%") then when I reboot, the service fails
to start. It is blocked by the lock file.

Log:
Mon Apr 30 16:02:07 [initandlisten] MongoDB starting : pid=2776 port=27017 dbpath=\\%NETWORK_DISK%\%PATH_TO_DB% 64-bit host=
Mon Apr 30 16:02:07 [initandlisten] db version v2.0.3, pdfile version 4.5
Mon Apr 30 16:02:07 [initandlisten] git version: 05bb8aa793660af8fce7e36b510ad48c27439697
Mon Apr 30 16:02:07 [initandlisten] build info: windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_42
Mon Apr 30 16:02:07 [initandlisten] options: { auth: true, dbpath: "\\%NETWORK_DISK%\%PATH_TO_DB%", logappend: true, logpath: "C:\%PATH_TO_LOG%\Mongo.log", service: true }
Mon Apr 30 16:02:11 shutdown: going to close listening sockets...
Mon Apr 30 16:02:11 shutdown: going to flush diaglog...
Mon Apr 30 16:02:11 shutdown: going to close sockets...
Mon Apr 30 16:02:11 shutdown: waiting for fs preallocator...
Mon Apr 30 16:02:11 shutdown: lock for final commit...
Mon Apr 30 16:02:11 shutdown: final commit...
Mon Apr 30 16:02:11 shutdown: closing all files...
Mon Apr 30 16:02:11 closeAllFiles() finished
Mon Apr 30 16:02:11 shutdown: removing fs lock...
Mon Apr 30 16:02:11 [initandlisten] journal dir=\\%NETWORK_DISK%\%PATH_TO_DB%/journal

[Tad Marshall]

I think that this is fixed in 2.1.0.  The symptoms and conditions will sound wrong in https://jira.mongodb.org/browse/SERVER-2833 , but the essence of that bug was that the server wasn't shutdown properly in some cases when running as a Windows service.  Your sequence of "start the service; reboot" would have triggered this bug.

Can you try 2.1.0 and see if it fixes your problem?

On Monday, April 30, 2012 9:02:12 AM UTC-4, ogoletti wrote:

[ogoletti]

Hi Tad,

Thanks for the answer. Indeed, it is solved in this release. I tried with 2.1.0 and it worked.
Do we know when it will be released as production release? Or is there a kind of patch available for the current production release (I think 2.0.4) ?
I guess it's not recommended to use a development release in production...

Thanks again,

O

[Tad Marshall]

I'm glad that 2.1.0 fixed your problem, thanks for letting us know!

We are working hard to get to a stable 2.2.0 release, but the timing is still in flux ... it depends on the feedback we get on the intermediate "unstable" releases.  Version 2.1.1 was just released and there will be at least a 2.1.2 test version before 2.2.0 is released.

It is not recommended to run "unstable" releases in production.

If you can modify your procedures a bit, issuing a "use admin" followed by a "db.shutdownServer()" command before you reboot should eliminate these problems.  The issue is in the timing of shutdown notifications when you reboot your server, which is probably why the networked disk became an issue ... it is enough slower to change the order of notifications that MongoDB sees.  By issuing a db.shutdownServer() command before you reboot, you avoid the timing issue and MongoDB will shut down cleanly every time.