[SERVER-7711] fsyncLock() makes mongod unusable if no databases have been opened yet Created: 19/Nov/12  Updated: 15/Feb/13  Resolved: 06/Dec/12

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Tyler Brock Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


Issue Links:
Duplicate
duplicates SERVER-1423 reads often aren't possible while in ... Closed
Operating System: ALL
Participants:

 Description   

Running db.fsyncLock() causes mongod to become permanently locked and unusable if no databases have been opened. User can't unlock it or re-connect to the mongod. SIG-TERM also is non-functional.

It seemed to quit with SIG-QUIT.

It seems as though when you run `show dbs` it works as expected (databases are opened), but when you don't it breaks.

  • Not Working

    MongoDB shell version: 2.2.1
    connecting to: test
    > db.fsyncLock()
    {
    	"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
    	"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
    	"ok" : 1
    }
    > db.foo.find()
    # You've just made mongod very unhappy

  • Working

    MongoDB shell version: 2.2.1
    connecting to: test
    > show dbs
    10gen-hc-2012-8-14	0.203125GB
    10gen-hc-2012-9-14	0.203125GB
    admin	0.203125GB
    foo	0.203125GB
    hub	0.203125GB
    local	(empty)
    mongo-dev	0.203125GB
    mongo_hadoop	0.453125GB
    ruby-test-db	0.203125GB
    ruby487_development	0.203125GB
    somedb	0.203125GB
    test	0.203125GB
    training	0.203125GB
    > db.fsyncLock()
    {
    	"info" : "now locked against writes, use db.fsyncUnlock() to unlock",
    	"seeAlso" : "http://dochub.mongodb.org/core/fsynccommand",
    	"ok" : 1
    }
    > db.foo.find()
    { "_id" : ObjectId("508e9b8b08d6faac46000000"), "foo" : 2 }
    > 



 Comments   
Comment by Tyler Brock [ 07/Dec/12 ]

I'm not sure this is a duplicate of the issue referenced... this is a different issue/bug.

Generated at Thu Feb 08 03:15:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.