Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detected unclean shutdown - /data/db/mongod.lock is not empty. #62

Closed
kevinsimper opened this issue Oct 21, 2015 · 14 comments
Closed

Detected unclean shutdown - /data/db/mongod.lock is not empty. #62

kevinsimper opened this issue Oct 21, 2015 · 14 comments

Comments

@kevinsimper
Copy link

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
Copy link
Author

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
Copy link
Member

@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
Copy link
Author

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

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

@yosifkit
Copy link
Member

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
Copy link

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

This worked for me, thanks!

@viniciusffj
Copy link

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
Copy link

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
Copy link

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

@athiselvam
Copy link

athiselvam commented Aug 21, 2017

Use following command to clean mongodb db path

mongod --repair

and then start your db.

@yosifkit
Copy link
Member

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
Copy link

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
Copy link

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

@Tom5om
Copy link

Tom5om commented Dec 22, 2019

Thanks @athiselvam

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

@bora89
Copy link

bora89 commented Feb 2, 2022

docker-compose run db mongod --repair (Where db is your container name)

This is the most accurate solution, BUT db is not a container name if you are using docker-compose it is rather service name.
Container names are only for a docker itself, not for docker-compose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests