MYSQL_DATABASE does not create database about mariadb-docker

[thaJeztah]

I see you're bind-mounting a directory (/srv/librenms/db), is this the first time you run a container using this directory? Was the directory empty before running the container? (the image will only initialize the database if the data directory is empty; see this line in the entrypoint script; https://github.com/docker-library/mariadb/blob/cc686f56875aa84d135bb89de6ca50385211bdab/10.1/docker-entrypoint.sh#L36)

[danielecr]

sorry, still checking this. It looks like database initialization take looooooong time, more than what i expected.

Anyway I hope it is usefull my comment to anyone facing this problem with little patience like me

[gezichenshan]

I checked this solution and saved my life. He changed the volumn name and worked! The answer says it might the data layer might not be recreated.

Could you give some detailed info?

[rosshettel]

Ah thanks for pointing that out. The directory already existed as I ran the container earlier without the env variable set, so that's why it didn't get created on startup. I'll close this then, thanks again!

[thaJeztah]

You're welcome!

On 10 Jul 2016, at 03:56, Ross Hettel [email protected] wrote:

Ah thanks for pointing that out. The directory already existed as I ran the container earlier without the env variable set, so that's why it didn't get created on startup. I'll close this then, thanks again!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[danielecr]

well no. It does not work.

In fact this is my composer:

services:
    mariadb:
        image: mariadb
        volumes:
            - ./dbdata:/docker-entrypoint-initdb.d
        environment:
            - MYSQL_ROOT_PASSWORD=rootte
            - MYSQL_DATABASE=sswsuitecrm
            - MYSQL_USER=sswsuitecrm
            - MYSQL_PASSWORD=suitepwd

and

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.001 sec)

on first run

same when running with a void folder

[LeDOC666]

Hello, I have the same problem, (And I think waited so much)
Here is my command:
docker run -d --name wp-mysql --network wp-network -v /data/wordpress/mysql:/var/lib/mysql -e MYSQL_USER=wordpress_user -e MYSQL_PASSWORD=wp_passmord -e MYSQL_DATABASE=wordpress -e MYSQL_RANDOM_ROOT_PASSWORD=1 mariadb

I deleted all /data/wordpress/mysql/* before, and still no database created !?

[LeDOC666]

ok, I have to wait 30 min 👍

[yosifkit]

@LeDOC666, that sounds like #262.

[gezichenshan]

Hi, my compose file is like:

version: "2"
services:
  mariadb_local:
    build:
      context: ./src
      dockerfile: mariadb-dockerfile
      args:
        MYSQL_DATABASE: dev
        MYSQL_ROOT_PASSWORD: dev
    container_name: mariadb_local
    restart: always
    ports:
      - 3306:3306
    volumes:
      - ./mariadb/data:/data
    environment:
      MYSQL_DATABASE: dev
      MYSQL_ROOT_PASSWORD: dev

and mariadb-dockerfile:

FROM mariadb

ADD dev.sql /docker-entrypoint-initdb.d

And I didn't see the dev DB created when I exec into mysql container.

P.S. I added build args because I see the doc says If your service specifies a build option, variables defined in environment are not automatically visible during the build. Use the args sub-option of build to define build-time environment variables. but still have no specified MYSQL_DATABASE created.

What am I missing?

[danielecr]

https://docs.docker.com/engine/reference/builder/#add
yes, probably it was this missing:

If <dest> does not end with a trailing slash, it will be considered a regular file and the contents of <src> will be written at <dest>

so this line

ADD dev.sql /docker-entrypoint-initdb.d

should have been

ADD dev.sql /docker-entrypoint-initdb.d/

EDIT: the . in documentation is meant as the end of the sentence, nothing to do with . directory!

[gezichenshan]

@danielecr Thanks!
You are right that I made a mistake forgot to add a slash in the end.

And another thing I think it is the build command in docker-compose file will only be executed at the first time when you do docker-compose up. The image will not be rebuilt the second time you type the same command. So if the first time the config is wrong in your dockerfile, you input docker-compose up then the wrong layer is added to the image. And the second time you will get same wrong result though you've changed the dockerfile.

So you should rebuild the image first and then up the container: type docker-compose build | docker-compose up to explicitly tell the docker to rebuild the image. Then the docker image layer will be changed and you will probably get desired result.

It is just a guess. I didn't verify it.

[danielecr]

yes, that is also true. A shorter version is docker-compose --build up
(all on doc https://docs.docker.com/compose/reference/up/ as usual)

[Shadow8472]

I see you're bind-mounting a directory (/srv/librenms/db), is this the first time you run a container using this directory? Was the directory empty before running the container? (the image will only initialize the database if the data directory is empty; see this line in the entrypoint script; https://github.com/docker-library/mariadb/blob/cc686f56875aa84d135bb89de6ca50385211bdab/10.1/docker-entrypoint.sh#L36)

Thank you for this key piece of advice. I've been pruning volumes instead of fully removing them while trying to get a Nextcloud pod assembly script together. I found leftover gunk in my volume from an earlier attempt. Thank you so much!

podman volume rm <volumeName>