Mongo: Detected unclean shutdown - /data/db/mongod.lock is not empty.

[kevinsimper]

c logs db
Attaching to blackbeardapp_db_1
db_1 | 2015-10-21T11:26:35.600+0000 W -        [initandlisten] Detected unclean shutdown - /data/db/mongod.lock is not empty.
db_1 | 2015-10-21T11:26:35.604+0000 I STORAGE  [initandlisten] **************
db_1 | old lock file: /data/db/mongod.lock.  probably means unclean shutdown,
db_1 | but there are no journal files to recover.
db_1 | this is likely human error or filesystem corruption.
db_1 | please make sure that your journal directory is mounted.
db_1 | found 2 dbs.
db_1 | see: http://dochub.mongodb.org/core/repair for more information
db_1 | *************
db_1 | 2015-10-21T11:26:35.606+0000 I STORAGE  [initandlisten] exception in initAndListen: 12596 old lock file, terminating
db_1 | 2015-10-21T11:26:35.606+0000 I CONTROL  [initandlisten] dbexit:  rc: 100

Here is my docker-compose config, you can see that i don't mount any volumes.

db:
  image: mongo:3.0.7
  ports:
   - "27017:27017"

I guess it is because of a faulted mount with virtualbox, but searched in the issues and found nobody had report this problem.

Does anybody know how to solve this?

[kevinsimper]

I think the reason was because I have recently upgraded to El Capitan and googling there seems to be some permission problems.

http://superuser.com/a/952616/166362

[yosifkit]

@kevinsimper were you able to fix it?

There is a docker managed volume defined in the Dockerfile, and compose will try hard to keep that between restarts of the container so that your data remains intact. It looks like the mongodb container was killed uncleanly on your last shutdown and so it still has the old lock file. Since there is no journal file it should be fine to do a docker-compose run db rm /data/db/mongod.lock. Then you should be fine to do a compose up.

[kevinsimper]

@yosifkit Thanks for replying! Yes, the problem seems be solved now when i upgraded/reinstalled Virtualbox and deleted my default docker-machine :smile:

I did not mount any volumes, so how would the db have a volume attached? I did not know that

[yosifkit]

Since there is a VOLUME definition in the Dockerfile, docker will create a docker managed volume (https://docs.docker.com/userguide/dockervolumes/#data-volumes) and docker-compose tries really hard to not delete it so that data will be preserved. Use docker-compose rm -v db to get rid of the database and its volume.

[giovannic]

Use docker-compose rm -v db to get rid of the database and its volume.

This worked for me, thanks!

[viniciusffj]

This issue is happening every time for me, so I usually need to run docker-compose rm -v db before I do docker-compose up.
Is there a way that I can fix this by changing the docker-compose.yml?

[mahnunchik]

How to fix it?

mongo_1  | 2016-08-10T07:37:41.489+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=c9628fef3cb4
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] db version v3.2.8
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] git version: ed70e33130c977bda0024c125b56d159573dbaf0
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] allocator: tcmalloc
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] modules: none
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] build environment:
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten]     distmod: debian71
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten]     distarch: x86_64
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten]     target_arch: x86_64
mongo_1  | 2016-08-10T07:37:41.490+0000 I CONTROL  [initandlisten] options: {}
mongo_1  | 2016-08-10T07:37:41.505+0000 I -        [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
mongo_1  | 2016-08-10T07:37:41.505+0000 W -        [initandlisten] Detected unclean shutdown - /data/db/mongod.lock is not empty.
mongo_1  | 2016-08-10T07:37:41.505+0000 I STORAGE  [initandlisten] exception in initAndListen: 98 Unable to lock file: /data/db/mongod.lock errno:11 Resource temporarily unavailable. Is a mongod instance already running?, terminating

docker-compose.yml

version: '2'
services:
  mongo:
    image: mongo:3
    restart: on-failure:10
    volumes:
      - mongo:/data/db

volumes:
  mongo:
    driver: local

Steps to reproduce:

$ docker-compose up
Ctrl + C
^CGracefully stopping... (press Ctrl+C again to force)
$ docker-compose up

[monabhardwaj]

Hi, I'm facing the same issue. Did you get a solution for it?
Would be very helpful

[athiselvam]

Use following command to clean mongodb db path

mongod --repair

and then start your db.

[yosifkit]

Closing old issue. Feel free to comment on further troubleshooting if you feel this was closed in error or on the solution to help users running into the same problem.

[iAssureIT]

I am facing same issue. But I do not want to lose data what will be the right command to do so?

Thanks in advance.

[rashmimhatre100]

Not sure which command to choose so that I can retrieve my data without fail. Please help me out with this. TIA

[Tom5om]

Thanks @athiselvam

If you are running the mongo docker container you can:
docker-compose run db mongod --repair (Where db is your container name)