Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-2079

Authenticated Connections do not get terminated when dropDatabase() command is issued.

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 1.6.3
    • Component/s: None
    • None
    • Environment:
      ubuntu 10.04
    • ALL

      If the user has an active connection to a particular database, with the server running in an authenticated environment, if you go into the MongoDB shell and execute a `db.dropDatabase()` or `db.getSisterDB('db_name').dropDatabase()` the data is dropped, but the authenticated connections are left open allowing the system to recreate the database.

      A temporary workaround is to restart /etc/networking to kill all active connections or restart mongodb for it to take effect. This is a pretty big bug for the MongoDB hosts out there like ourselves.

      Here is a gist below of what the log output says: https://gist.github.com/9a6e2b1b81917d18b11c

      Tue Nov 9 04:31:41 [conn65729] run command clobby-staging.$cmd

      { dropDatabase: 1.0 }

      Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging
      Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging

      Tue Nov 9 04:31:41 [conn65729] run command clobby-staging.$cmd

      { dropDatabase: 1.0 }

      Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging
      Tue Nov 9 04:31:41 [conn65729] dropDatabase clobby-staging
      Tue Nov 9 04:31:41 [conn4] getmore local.oplog.$main cid:5068368097862225500 getMore: { ts:

      { $gte: new Date(5534923916268535809) }

      } bytes:105 nreturned:1 3282ms
      Tue Nov 9 04:31:41 [conn65729] query clobby-staging.$cmd ntoreturn:1 command:

      { dropDatabase: 1.0 }

      reslen:81 12ms

      Tue Nov 9 04:31:42 [conn65447] Accessing: clobby-staging for the first time
      Tue Nov 9 04:31:42 [conn65447] query clobby-staging.rooms ntoreturn:1 reslen:36 nreturned:0 0ms
      Tue Nov 9 04:31:42 allocating new datafile /data/mongodb/clobby-staging/clobby-staging.ns, filling with zeroes...
      Tue Nov 9 04:31:42 done allocating datafile /data/mongodb/clobby-staging/clobby-staging.ns, size: 16MB, took 0.002 secs
      Tue Nov 9 04:31:42 allocating new datafile /data/mongodb/clobby-staging/clobby-staging.0, filling with zeroes...
      Tue Nov 9 04:31:42 done allocating datafile /data/mongodb/clobby-staging/clobby-staging.0, size: 64MB, took 0.001 secs
      Tue Nov 9 04:31:42 allocating new datafile /data/mongodb/clobby-staging/clobby-staging.1, filling with zeroes...
      Tue Nov 9 04:31:42 [conn65447] New namespace: clobby-staging.rooms
      New namespace: clobby-staging.system.namespaces
      adding _id index for collection clobby-staging.rooms
      Tue Nov 9 04:31:42 [conn65447] New namespace: clobby-staging.system.indexes
      building new index on

      { _id: 1 }

      for clobby-staging.rooms
      Tue Nov 9 04:31:42 [conn65447] external sort root: /data/mongodb/_tmp/esort.1289277102.2034221856/
      Tue Nov 9 04:31:42 [conn65447] external sort used : 0 files in 0 secs
      Tue Nov 9 04:31:42 done allocating datafile /data/mongodb/clobby-staging/clobby-staging.1, size: 128MB, took 0.001 secs
      Tue Nov 9 04:31:42 [conn65447] New namespace: clobby-staging.rooms.$id
      done building bottom layer, going to commit
      Tue Nov 9 04:31:42 [conn65447] fastBuildIndex dupsToDrop:0
      Tue Nov 9 04:31:42 [conn65447] done for 0 records 0secs
      Tue Nov 9 04:31:42 [conn4] getmore local.oplog.$main cid:5068368097862225500 getMore: { ts:

      { $gte: new Date(5534923916268535809) }

      } bytes:184 nreturned:1 798ms
      Tue Nov 9 04:31:42 [conn65447] insert clobby-staging.rooms 60ms

            Assignee:
            Unassigned Unassigned
            Reporter:
            jsmestad Justin Smestad
            Votes:
            5 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: