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

DB Connection failed #80

Closed
Wulfheart opened this issue Jan 1, 2019 · 11 comments
Closed

DB Connection failed #80

Wulfheart opened this issue Jan 1, 2019 · 11 comments

Comments

@Wulfheart
Copy link

Today I got this repository and ran docker-compose up. This is the (wrong) output? Any way to fix this?

api_1  | ?? Database connection has failed! Make sure your database is running.
db_1   | 2019-01-01T21:04:59.757+0000 I CONTROL  [main] Automatically disablingTLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
db_1   | 2019-01-01T21:04:59.761+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=808f20fb3234
db_1   | 2019-01-01T21:04:59.761+0000 I CONTROL  [initandlisten] db version v4.0.5
db_1   | 2019-01-01T21:04:59.762+0000 I CONTROL  [initandlisten] git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
db_1   | 2019-01-01T21:04:59.762+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
db_1   | 2019-01-01T21:04:59.762+0000 I CONTROL  [initandlisten] allocator: tcmalloc
db_1   | 2019-01-01T21:04:59.763+0000 I CONTROL  [initandlisten] modules: none
db_1   | 2019-01-01T21:04:59.763+0000 I CONTROL  [initandlisten] build environment:
db_1   | 2019-01-01T21:04:59.763+0000 I CONTROL  [initandlisten]     distmod: ubuntu1604
db_1   | 2019-01-01T21:04:59.764+0000 I CONTROL  [initandlisten]     distarch: x86_64
db_1   | 2019-01-01T21:04:59.764+0000 I CONTROL  [initandlisten]     target_arch: x86_64
db_1   | 2019-01-01T21:04:59.764+0000 I CONTROL  [initandlisten] options: { net: { bindIpAll: true } }
db_1   | 2019-01-01T21:04:59.767+0000 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=478M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
api_1  |
api_1  | ? Testing database connection...
db_1   | 2019-01-01T21:05:00.508+0000 E STORAGE  [initandlisten] WiredTiger error (17) [1546376700:508011][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists Raw: [1546376700:508011][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
db_1   | 2019-01-01T21:05:00.509+0000 I STORAGE  [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.54
db_1   | 2019-01-01T21:05:00.512+0000 E STORAGE  [initandlisten] WiredTiger error (1) [1546376700:512304][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1546376700:512304][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
db_1   | 2019-01-01T21:05:00.536+0000 E STORAGE  [initandlisten] WiredTiger error (17) [1546376700:536266][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists Raw: [1546376700:536266][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
db_1   | 2019-01-01T21:05:00.539+0000 I STORAGE  [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.55
db_1   | 2019-01-01T21:05:00.540+0000 E STORAGE  [initandlisten] WiredTiger error (1) [1546376700:540816][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1546376700:540816][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
db_1   | 2019-01-01T21:05:00.568+0000 E STORAGE  [initandlisten] WiredTiger error (17) [1546376700:568896][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists Raw: [1546376700:568896][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
db_1   | 2019-01-01T21:05:00.571+0000 I STORAGE  [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.56
db_1   | 2019-01-01T21:05:00.572+0000 E STORAGE  [initandlisten] WiredTiger error (1) [1546376700:572889][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1546376700:572889][1:0x7faa14660a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
db_1   | 2019-01-01T21:05:00.574+0000 W STORAGE  [initandlisten] Failed to start up WiredTiger under any compatibility version.
db_1   | 2019-01-01T21:05:00.574+0000 F STORAGE  [initandlisten] Reason: 1: Operation not permitted
db_1   | 2019-01-01T21:05:00.574+0000 F -        [initandlisten] Fatal Assertion 28595 at src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 638
db_1   | 2019-01-01T21:05:00.574+0000 F -        [initandlisten]
db_1   |
db_1   | ***aborting after fassert() failure
db_1   |
db_1   |
strapi-docker_db_1 exited with code 14
@batjko
Copy link

batjko commented Jan 22, 2019

I'm seeing the same thing, on Windows 10, as well as Linux.

image

@msgeissler
Copy link
Contributor

For Windows and Mac OSX you might run into problems with the docker-compose.yml in this repo as it mounts a folder from the host system.

Please see https://hub.docker.com/_/mongo -> Scroll down to Caveats -> Where to Store Data
and read the warning.

But that should not explain the error on Linux. Maybe more of the logs can help.

@MatteoGioioso
Copy link

MatteoGioioso commented Feb 16, 2019

Exact same error on Window 10.
@msgeissler in the link you provided does it say to run mongo container via docker container run instead of compose file? Is that correct?
Otherwise I did not get it 😄

At the moment just for testing I have disabled volumes and seems to work.
Thanks

@msgeissler
Copy link
Contributor

@MatteoGioioso with the link I was specifically referring to the mentioned caveats section in the mongodb container documentation. On Windows and Mac OSX you cannot use folders mounted from the host to store data for mongodb, which is currently the case with the Docker compose file provided in this repository.

You will have to use Docker volumes if you wish to persist the data for longer usage, otherwise you might lose any data stored in the mongodb container when you remove it (e.g. for updating to a new version).

@MatteoGioioso
Copy link

MatteoGioioso commented Feb 17, 2019

@msgeissler Sorry if I still did not get it.
You are saying that in this case bind mounts are not working and instead we should use just volumes.
Ex: instead of:

 volumes:
      - ./db:/data/db

just

volumes:
      - /data/db

Thanks

@msgeissler
Copy link
Contributor

msgeissler commented Feb 17, 2019

@MatteoGioioso you should read the storage overview of docker to get a basic knowledge of the different types of storage docker has: https://docs.docker.com/storage/
The two important ones for now are volumes and bind mounts.

For mongodb (and this applies to other containers as well, mainly databases) bind mounts on Windows and OS X are not support. From the mongo docker page:

WARNING (Windows & OS X): The default Docker setup on Windows and OS X uses a VirtualBox VM to host the Docker daemon. Unfortunately, the mechanism VirtualBox uses to share folders between the host system and the Docker container is not compatible with the memory mapped files used by MongoDB (see vbox bug, docs.mongodb.org and related jira.mongodb.org bug). This means that it is not possible to run a MongoDB container with the data directory mapped to the host.

(The VirtualBox VM part, as far as I know, is outdated. At least on Windows it uses Hyper-V, but basically still an additional layer of virtualisation)

As you already mentioned, you need docker volumes for mongodb on these operating systems. I would suggest you use named volumes, as they give you control over the name of the volume. It makes it easier to maintain the lists of important volumes on your system and anonymous volumes can also be removed automatically with certain docker CLI arguments (much easier to accidentally lose data).
Please see the docker documentation for docker-compose files on that: https://docs.docker.com/compose/compose-file/#volume-configuration-reference
Note the volumes- definition for the example db-service and the volumes-definition at the bottom.

@batjko
Copy link

batjko commented Feb 26, 2019

To be clear, I already removed the volumes from my compose file, because I know on Windows the paths will be different and I just wanted to get the compose stack running for once, before deciding where to persist the data.

So the mounts are not the problem I had, me thinks.

@msgeissler
Copy link
Contributor

@batjko hmmm, the best I can find on this still relates to a permission problem with mounting host volumes on Windows: docker-library/mongo#74

I am not sure what is going on in your case, but it looks like this is more related to docker and mongo.

This may sound a bit counter intuitive, but could you try it again with an explicitly defined / named volume?
If that does not work either, you may have more luck asking in the mongodb repository.

@anindoasaha
Copy link

Here's what worked for me:
docker-compose.yml

Add a volume for MongoDB:

volumes:
  mongodb_data:
    driver: local

Reference it in the db section:

db:
    image: mongo
    environment:
      - MONGO_INITDB_DATABASE=strapi
    ports:
      - 27017:27017
    volumes:
      - mongodb_data:/data/db
    restart: always

@adnoh
Copy link

adnoh commented Aug 5, 2019

Why is this closed when it is not fixed? A new user like me wanted to try out strapi - is going away after it isn't working with a simple docker ....
The workaround from anindoasaha is good - why not merging it in?

@Wulfheart
Copy link
Author

It seems that he hasn't made a pull request. Maybe you could make one. This should be a quick one.

adnoh added a commit to adnoh/strapi-docker that referenced this issue Aug 11, 2019
For mongodb (and this applies to other containers as well, mainly databases) bind mounts on Windows and OS X are not support.
So to Fix strapi#80 we move its data into its own volume
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

Successfully merging a pull request may close this issue.

7 participants