docker-entrypoint-initdb.d is not working

[skarpushin]

I have 2 virtual machines:
• One is based on Mint 18.2 Mate
• Other is based on Mint 18.3 Mate

On both I have installed Docker and Docker-compose.
On both --version shows same info

• Docker version 17.05.0-ce, build 89658be
• docker-compose version 1.8.0, build unknown

I'm invoking docker-compose up

On 18.2 mapping for docker-entrypoint-initdb.d gets picked up and sql scripts are executed. But on 18.3 it doesn't happen and it's not even saying that file is ignored -- just nothing.

I'm using the very same docker-compose file, you can check it out here: https://github.com/skarpushin/summerb/tree/master/src/summerb/summerb_tests_db

On 18.2 this section of log looks like:

mariadb_1  | 180428 17:20:21 [Warning] 'proxies_priv' entry '@% root@bb430dbcf809' ignored in --skip-name-resolve mode.
mariadb_1  | 
mariadb_1  | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/s01_user-service.sql
mariadb_1  | 
mariadb_1  | 
mariadb_1  | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/s02_property-service.sql
mariadb_1  | 
mariadb_1  | 
mariadb_1  | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/s03_article-service.sql
mariadb_1  | 
mariadb_1  | 
mariadb_1  | 180428 17:20:22 [Note] mysqld: Normal shutdown

On 18.3 this section of log looks like:

mariadb_1  | 180428 18:01:59 [Warning] 'proxies_priv' entry '@% root@71df66b47bf2' ignored in --skip-name-resolve mode.
mariadb_1  | 
mariadb_1  | 180428 18:01:59 [Note] mysqld: Normal shutdown

I just wasted 5 hours on thing which supposed to work everywhere the same way, but it doesn't. Please help to find out why and how to fix it.

[skarpushin]

I found an old backup of the very same machine mint 18.3 and same thing worked there. SO it's really hard to reproduce =(.

I'll close this issue.

[numbworks]

Hello guys,

I hope you are well.

Short description
I have exactly the same issue: the .sql script contained inside the "docker-entrypoint-initdb.d" folder gets ignored when I run docker-compose.yml on my production environment (Linux), while exactly the same file works flawlessy on my development environment (Windows 7).

This doesn't allow me to build the database structure (the .sql file contains all the CREATE TABLE statements...), therefore it's a major showstopper for me.

Detailed description
I tried the following solutions:

• Changing EOL for the .sql from CRLF to LF;
• Various chmod settings for "docker-entrypoint-initdb.d" (and contained scripts);
• Entering the container with "docker exec" (both folder and scripts are accessible from within the container as expected);
• Adding a *.sh file to "docker-entrypoint-initdb.d" (it gets ignored exactly as the .sql);

No success so far. Checking the logs with:

$ docker logs someappname_db >& logs_db.txt

shows that the following block of code from docker-entrypoint.sh doesn't get called at all on the Linux environment:

                for f in /docker-entrypoint-initdb.d/*; do
                        case "$f" in
                                *.sh)     echo "$0: running $f"; . "$f" ;;
                                *.sql)    echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;;
                                *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;;
                                *)        echo "$0: ignoring $f" ;;
                        esac
                        echo
                done

On a thread on StackOverflow (), an user who runs a mysql container has the same issue, and he said he solved it changing:

          `  for f in /docker-entrypoint-initdb.d/*; do`

with:

for f in /usr/local/bin/docker-entrypoint-initdb.d/*; do

mysql's docker image seems to have exactly the same docker-entrypoint.sh as mariadb's one.
Could that be the issue?

Entering the container with "docker exec", I see the following permissions:

On Linux:

root@deda78e393f9:/# ls -l
total 72
drwxr-xr-x    2 root root 4096 Mar 19 19:53 bin
drwxr-xr-x    2 root root 4096 Nov 19 16:32 boot
drwxr-xr-x    5 root root  340 Apr 29 15:53 dev
**drwxrwxrwx+   2 root root 4096 Apr 29 11:30 docker-entrypoint-initdb.d**
lrwxrwxrwx    1 root root   34 Mar 14 06:26 docker-entrypoint.sh -> usr/local/bin/docker-entrypoint.sh
...

On Windows 7:

root@a3ff19060712:/# ls -l
total 64
drwxr-xr-x   2 root root  4096 Feb 17 09:07 bin
drwxr-xr-x   2 root root  4096 Nov 19 16:32 boot
drwxr-xr-x   5 root root   340 Apr 29 16:04 dev
**drwxrwxrwx   1 1000 staff    0 Apr 28 18:13 docker-entrypoint-initdb.d**
lrwxrwxrwx   1 root root    34 Feb 17 09:08 docker-entrypoint.sh -> usr/local/bin/docker-entrypoint.sh
...

Could it be related to the UID:GID?
Should them be 1000:staff as well on Linux?

The user on my Linux host is called 'admin', could be perhaps a mismatch root (on container) : admin (on host) thingy?

Specifications
Development environment: Windows 7, Docker 18.02.0-CE
Production environment: unspecidfied flavour of Linux (QNAP TS-253A), Docker 17.07.0-CE

[/share/Container/] # uname -or
4.2.8 GNU/Linux

[/share/Container/] # cat /etc/issue
Welcome to TS-253A, QNAP Systems, Inc.

[/share/Container/] # cat /etc/os-release
NAME="QTS"
VERSION="4.3.4 (20180215)"
ID=qts
PRETTY_NAME="QTS 4.3.4 (20180215)"
VERSION_ID="4.3.4"

docker-compose.yml

version: '3'
services:

  db:
    container_name: someappname_db
    image: mariadb:latest
    restart: on-failure:3
    environment: 
      - MYSQL_DATABASE=someappname
      - MYSQL_ROOT_PASSWORD=someappname
      - MYSQL_USER=someappname
      - MYSQL_PASSWORD=someappname
      - MYSQL_ROOT_HOST=%
      - TZ=Europe/Stockholm
    ports:
      - 3306:3306  
    volumes:
      - dbdata:/var/lib/mysql      
      - /share/Container/someappname/docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d:ro
    networks:
      - net
    command: ["mysqld", "--user=mysql", "--lower_case_table_names=1"]

    # other services

volumes:
  dbdata:

networks:
  net:

Commands:

I always clean-up the volume before re-composing the container:

$ cd /share/Containers/someappname
$ docker stop $(docker ps -a -q --filter="name=someappname") && docker rm $(docker ps -a -q  --filter="name=someappname") && docker volume rm someappname_dbdata
$ docker-compose -f someappnameprod-docker-compose.yml up -d db

Thank you for your kind help!

[tanji]

@numbworks if you run this code manually inside the container, does it work at all?

                for f in /docker-entrypoint-initdb.d/*; do
                        case "$f" in
                                *.sh)     echo "$0: running $f"; . "$f" ;;
                                *.sql)    echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;;
                                *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;;
                                *)        echo "$0: ignoring $f" ;;
                        esac
                        echo
                done

Also note that this code will only run if the DB is not pre-initialized - but as you delete the volume this shouldn't happen.
Could you also check the version of bash in your container? bash --version

[numbworks]

@tanji
Hey Guillaume,

thank your for looking into this : )

bash --version:

root@2af3df7188a0:/# bash --version
GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)

for-deid.sh

#!/bin/bash

for f in /docker-entrypoint-initdb.d/*; do
		case "$f" in
				*.sh)     echo "$0: running $f"; . "$f" ;;
				*.sql)    echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;;
				*.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;;
				*)        echo "$0: ignoring $f" ;;
		esac
		echo
done

for-deid.sh's output

root@2af3df7188a0:/# bash for-deid.sh
for-deid.sh: running /docker-entrypoint-initdb.d/echo-test.sh
test test test test test test test test test test

for-deid.sh: running /docker-entrypoint-initdb.d/someappname_createdatabase-prod.sql

root@2af3df7188a0:/#

It seems that runs the test .sh that I put inside docker-entrypoint-initdb.d just fine, but it doesn't run this piece "${mysql[@]}" < "$f" ?

MariaDB [someappname]> SHOW TABLES;
Empty set (0.00 sec)

MariaDB [someappname]>

And mariadb's user + password have been correctly created.

Other information:

"ls -l docker-entrypoint-initdb.d/"

root@2af3df7188a0:/# ls -l docker-entrypoint-initdb.d/
total 40
-rwxrwxrwx+ 1 root root 71 Apr 29 20:51 echo-test.sh
-rwxrwxrwx+ 1 root root 28289 Apr 28 17:21 someappname_createdatabase-prod.sql

"echo-test.sh

#!/bin/bash

echo "test test test test test test test test test test"

What I'll try is to configure my Raspberry Pi 3 in the following days, and see if it behaves the same way there.

Thanks,
Rubèn

[skarpushin]

Actually I want to re-open this issue. I just installed fresh machine using Linux Min 18.3 x64 and I can reproduce the issue.

[skarpushin]

I tried 2 fresh installations of Linux Mint 18.2 and 18.3. In both cases it doesn't work. It looks like there is some broken package that gets installed during Docker installation process OR it's one of the docker images

[tanji]

@numbworks I've rarely used the entrypoint.d function but I'll give it a shot and be back at you. BTW, you shouldn't use mariadb:latest tag in production as you could run in some trouble when 10.3 is released :)

[tanji]

@numbworks Sorry I couldn't reproduce your issue. I ran the same Compose file with the following createdatabase.sql:

CREATE DATABASE toto;
USE toto;
CREATE TABLE t1 (id int);

This worked without any issues for me.
However, I would say that there's probably something wrong with the filesystem you're attempting to mount the files from. Indeed, if I look inside my container I have the following permissions:

root@118e84eeb8d0:/# ls -ld docker-entrypoint-initdb.d
drwxr-xr-x 2 1000 users 80 Apr 30 09:15 docker-entrypoint-initdb.d

It is indeed different from yours, which has a + sign for ACL - I have no idea what the two leading ** means, it's my first time seeing this in 20 years, and the ls docs don't mention it at all.
What I could recommend is using another directory, which would be possibly unaffected by ACL's or the like - I have no idea of what is this /share directory on QNAP meant for, but it isn't part of the LFS.

[skarpushin]

@tanji you probably tried to reproduce it on a system where you already have docker installed.
Do you have a chance to install fresh copy of Linux Mint 18.3 (on VirtualBox for example) and try to reproduce it there?

[tanji]

@skarpushin I'm sorry, your issue is completely different (the SQL didn't run, obviously...) and I didn't try to reproduce it. And I won't probably have no time for that, I'm not too familiar with Mint.

[skarpushin]

your issue is completely different

@tanji , could you please clarify -- in which way it is different?
Init SQL didn't run in my case in numbworks's cases -- based on the description the issue looks very same to me.
Which OS are you using?

[numbworks]

@tanji
Thank you for your time :)

Answers:

1. Yup, removing the mariadb:latest tag from the production YAML file is one of the fine-tunings I plan to do once I reach a YAML file that works trustworthly in both environments.
   To improve maintanability, I'll also evaluate to switch from a two-separate-YAML-files to a solution like the following: https://docs.docker.com/compose/production/#modify-your-compose-file-for-production

2. the ** are there because I was trying to highlight those two lines with the markdown, but it seems the bold doesn't work from within a code block;

3. I noticed the ACL '+' sign before, but I though it was related to the un-matching UID:GID between host and container, or similar. Having the confirmation that in another Linux environment it doesn't appear, it's a good hint for me, I'll research further :-)

'/share/Container' is the default folder that QNAP assigns to Docker.
It could be possible that the problem is something related to some custom filesystem/permissions configuration on the host, but I doubt it's QNAP devices-specific issue, since:

a) they market their Docker-capability quite intensively (so I believe they did some QA on it);
b) I'm running Gitlab containers (Gitlab+PostgresSQL+Redis) just fine on it;
c) according to Google, several persons have exactly this same issue on their Linux boxes.

Next weekend I'll investigate further and share my findings.
Let's see if we can sort it out :-)

Thanks,
Rubèn

[yosifkit]

Perhaps this docker-library/postgres#203 (comment) will help? In other words is the data directory empty when you start the container (the named volume from your compose)? The scripts are only run on first database creation; if you compose down/stop/kill and then up they will not run anything new.

[numbworks]

@yosifkit

Yup, I'm aware of that behaviour, and I always clean-up the volume before re-composing the container:

$ docker stop $(docker ps -a -q --filter="name=someappname") && docker rm $(docker ps -a -q  --filter="name=someappname") && docker volume rm someappname_dbdata
$ docker-compose -f someappnameprod-docker-compose.yml up -d db

At a certain point I even did some docker volume prune. , just in case.
On my production environment never worked, and at the first up there was any volume.

[numbworks]

UPDATE
I share more details, for documenting purpose.
I spent even this whole weekend on this issue:

• setup my Raspberry Pi 3 and tried to up the same docker-compose.yml there but no MariaDB image for ARM64 architecture yet, and I don't have other Linux environments at the moment (= no success);
• read several QNAP-specific threads about Docker (= no success);
• moved the docker-entrypoint-initdb.d folder on the host elsewhere on my QNAP (= no success);
• re-created all the folders using QNAP's web interface instead of samba+Windows (= no success);
• aligned the QNAP to the same MariaDB image (mariadb:10.2.14 => mariadb:10.2.13) that I have on my development environment (=no success).

I compared the Prod-env log with the Dev-eng log line-by-line, and here the differences.
The key-part is in the block 3.

1. ==========================

Same in both logs:

Initializing database

PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:

'/usr/bin/mysqladmin' -u root password 'new-password'
'/usr/bin/mysqladmin' -u root -h  password 'new-password'

Alternatively you can run:
'/usr/bin/mysql_secure_installation'

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the MariaDB Knowledgebase at http://mariadb.com/kb or the
MySQL manual for more instructions.

Please report any problems at http://mariadb.org/jira

The latest information about MariaDB is available at http://mariadb.org/.
You can find additional information about the MySQL part at:
http://dev.mysql.com
Consider joining MariaDB's strong and vibrant community:
https://mariadb.org/get-involved/

Database initialized

2. ==========================

Prod log:

2018-05-06 15:26:39 140076438214528 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2018-05-06 15:26:39 140076438214528 [Note] InnoDB: 5.7.21 started; log sequence number 1619996

Dev log:

2018-05-06 13:51:03 140009984444288 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2018-05-06 13:51:03 140009984444288 [Note] InnoDB: Waiting for purge to start
2018-05-06 13:51:04 140009984444288 [Note] InnoDB: 5.7.21 started; log sequence number 1620152

3. ==========================

Prod log:

2018-05-06 15:26:45 140076266211072 [Warning] 'proxies_priv' entry '@% root@219994496f8e' ignored in --skip-name-resolve mode.

2018-05-06 15:26:45 140076265174784 [Note] mysqld (initiated by: unknown): Normal shutdown

Dev log:

2018-05-06 13:51:08 140009326741248 [Warning] 'proxies_priv' entry '@% root@0d3260be248f' ignored in --skip-name-resolve mode.

/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/someappname_createdatabase-dev.sql



2018-05-06 13:51:14 140009326438144 [Note] mysqld (unknown): Normal shutdown

4. ==========================

Prod log:

2018-05-06 15:26:48 139903331444608 [Note] Plugin 'FEEDBACK' is disabled.
2018-05-06 15:26:48 139902226253568 [Note] InnoDB: Buffer pool(s) load completed at 180506 15:26:48
2018-05-06 15:26:48 139903331444608 [Warning] Failed to create a socket for IPv6 '::': errno: 97.
2018-05-06 15:26:48 139903331444608 [Note] Server socket created on IP: '0.0.0.0'.

Dev log:

2018-05-06 13:51:16 139911428560640 [Note] InnoDB: Buffer pool(s) load completed at 180506 13:51:16
2018-05-06 13:51:16 139912414726016 [Note] Plugin 'FEEDBACK' is disabled.
2018-05-06 13:51:17 139912414726016 [Note] Server socket created on IP: '::'.

[skarpushin]

@numbworks , that's for sharing this!
Btw, you experience matches mine (check the first post) in this thread.

So.. did you find how to fix that?

[numbworks]

@skarpushin
Nope, no success so far :-/ Spent already 40+ hours on this...

[numbworks]

UPDATE

I also exported the docker-entrypoint.sh from within the container, with the purpose to add some debug lines to it, and make the docker-compose.yml use my custom *entrypoint.sh instead of the standard one, but no luck so far.

Somebody on this thread has an idea how-to inject a custom docker-entrypoint.sh from within docker-compose.yml (without customizing the image)? Or how-to enable some kind of debugging mode inside Docker Compose to step thru the creational process (if this feature/flag exists)?

The case #1 seems expecially peculiar, because it seems that, when Docker Compose reaches the point to run the custom docker-entrypoint.sh, the MYSQL_* environment variables aren't available yet.

All the other cases return a permission error (?).

1. =========================

[/share/CACHEDEV1_DATA/Container/someappname] # ls -la
total 2672
drwxrwx--- 4 admin administrators   4096 2018-05-06 16:16 ./
drwxrwxrwx 5 admin administrators   4096 2018-05-06 11:28 ../
drwxrwx--- 3 admin administrators   4096 2018-05-06 16:16 _Deprecated/
drwxrwx--- 2 admin administrators   4096 2018-05-06 14:15 docker-entrypoint-initdb.d/
-rwxrwxrwx 1 admin administrators   5661 2018-05-06 16:14 docker-entrypoint.sh*
...

version: '3'
services:

  db:
    container_name: someappname_db
    image: mariadb:10.2.13
    restart: on-failure:3
    environment: 
      - MYSQL_DATABASE=someappname
      - MYSQL_ROOT_PASSWORD=someappname
      - MYSQL_USER=someappname
      - MYSQL_PASSWORD=someappname
      - MYSQL_ROOT_HOST=%
      - TZ=Europe/Stockholm
    ports:
      - 3306:3306  
    volumes:
      - dbdata:/var/lib/mysql      
      - /share/CACHEDEV1_DATA/Container/someappname/:/someappname/:ro
    environment:      
      - /bin/bash
      - /someappname/docker-entrypoint.sh
    networks:
      - net
    command: ["mysqld", "--user=mysql", "--lower_case_table_names=1"]

volumes:
  dbdata:

networks:
  net:

$ docker logs someappname_db >& logs_db.txt

error: database is uninitialized and password option is not specified 
  You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

2, 3, 4. =========================

...
    volumes:
      - dbdata:/var/lib/mysql      
      - /share/CACHEDEV1_DATA/Container/someappname/docker-entrypoint.sh:/docker-entrypoint.sh:ro
...

...
    volumes:
      - dbdata:/var/lib/mysql
      - /share/CACHEDEV1_DATA/Container/someappname/docker-entrypoint.sh:/usr/local/bin/docker-entrypoint.sh:ro  
    environment:      
      - /usr/local/bin/someappname/docker-entrypoint.sh
...

...
    environment:
      - /bin/bash -c "chmod +x /usr/local/bin/someappname/docker-entrypoint.sh && /usr/local/bin/someappname/docker-entrypoint.sh" 
...

$ docker logs someappname_db >& logs_db.txt

error: exec failed: permission denied

[numbworks]

UPDATE

I did a counter-test. I added an un-supported file (.xlsx) to the docker-entrypoint-initdb.d folder on the host, just to see if the *ignoring* message would appear in the log.

[/share/CACHEDEV1_DATA/Container/someappname] # ls -la docker-entrypoint-initdb.d/
total 52
drwxrwx--- 2 admin administrators  4096 2018-05-06 18:23 ./
drwxrwx--- 4 admin administrators  4096 2018-05-06 16:16 ../
-rwxrwxrwx 1 admin administrators     0 2018-05-06 18:23 i_expect_this_to_be_ignored.xlsx*
-rwxrwxrwx 1 admin administrators 28289 2018-04-28 17:21 someappname_createdatabase-prod.sql*
...

2018-05-06 18:27:15 139940894009088 [Warning] 'proxies_priv' entry '@% root@dd1a08662d2a' ignored in --skip-name-resolve mode.
2018-05-06 18:27:15 139940894009088 [Warning] 'proxies_priv' entry '@% root@dd1a08662d2a' ignored in --skip-name-resolve mode.

2018-05-06 18:27:15 139940646061824 [Note] mysqld (unknown): Normal shutdown

It doesn't appear.
The following block from docker-entrypoint.sh gets totally ignored:

		echo
		for f in docker-entrypoint-initdb.d/*; do
			case "$f" in
				*.sh)     echo "$0: running $f"; . "$f" ;;
				*.sql)    echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;;
				*.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;;
				*)        echo "$0: ignoring $f" ;;
			esac
			echo
		done

[skarpushin]

Yep. And honestly I have NO idea, why.
Also it appears than the very same docker config works perfectly on machines where I've installed Docker long time ago. So it has something to do with current online repositories which used to to install docker on a machine.
Do you have old machine (with docker installed long time ago) to test on?

[numbworks]

@skarpushin
Nope, unfortunately I have no other x86 Linux machine available, and no resources for VMs :-/
But that wouldn't change things anyway, I need to find a workaround to make it working on my QNAP :-)

[yosifkit]

My current guess is permissions on the mounted folder. @numbworks gave this as his host permissions:

drwxrwx--- 2 admin administrators  4096 2018-05-06 18:23 ./

When the entrypoint script gets to the point of reading the docker-entrypoint-initdb.d directory, it is running as the mysql user of the container, which is 999 and so this user will not have access to list the contents of the mounted directory.

You can do a quick debugging test with the following. (It is running specifically as the mysql user so that we don't lose the bash -x when it re-execs to drop root.)

$ docker run -d -e MYSQL_ROOT_PASSWORD=12345 --user mysql -v [volume-mount] mariadb:10.2 bash -x docker-entrypoint.sh mysqld

The compose equivalent should be something like this inside the db service.

user: mysql
command:
  - bash
  - -x
  - docker-entrypoint.sh
  - mysqld

[numbworks]

@yosifkit
The following is an interesting insight:

When the entrypoint script gets to the point of reading the docker-entrypoint-initdb.d directory, it is running as the mysql user of the container, which is 999

I'll give a try to your suggests in the weekend, and get back to this thread :)

Rubèn

[hydrocat]

Hey @numbworks , can you try running a "standard" docker-composer file ?
I have a feeling that the line :

command: ["mysqld", "--user=mysql", "--lower_case_table_names=1"]

might have something to do with it as it overrides the command that the container would normally use.

I wrote this simple .yaml and it did load the .sql found in the docker-entrypoint.

services:                                                                                                                                              
  maria:                                                                                                                                               
    image: mariadb                                                                                                                                     
    environment:                                                                                                                                       
      MYSQL_ROOT_PASSWORD: root                                                                                                                        
    ports:                                                                                                                                             
      - "3306:3306"                                                                                                                                    
    volumes:                                                                                                                                           
      - ./maria:/docker-entrypoint-initdb.d/  

For the .sql, I used the Chinnok Database and put it in a folder called maria alongside the docker-compose.yaml.

[tanji]

@hydrocat command doesn't overwrite anything because it's passed through an entrypoint. So the above should work correctly.

[hydrocat]

@tanji compose-file reference seems to say otherwise

Command
Override the default command.

command: bundle exec thin -p 3000

The command can also be a list, in a manner similar to dockerfile:

command: ["bundle", "exec", "thin", "-p", "3000"]

[tanji]

@hydrocat I haven't explained myself correctly. You can override the default container command (in this case for mariadb the default command is mysqld, as noted here: https://github.com/docker-library/mariadb/blob/master/Dockerfile.template#L143

However, as the image uses an entrypoint, whatever override you use is always passed through the entrypoint. Full code here: https://github.com/docker-library/mariadb/blob/master/docker-entrypoint.sh
For example if you pass options, mysqld is always preprended.

This way it's absolutely safe to override the command with additional options (unless, of course, you change the command by something else than mysqld...). I do it frequently without harm.

[mindreader]

Here's what I found. This may not apply to everyone, but it applied to me.

Somewhere in the docker-entrypoint.sh, there's a block of code

if [ -z "$MYSQL_INITDB_SKIP_TZINFO" ]; then
  # sed is for https://bugs.mysql.com/bug.php?id=20545
  mysql_tzinfo_to_sql /usr/share/zoneinfo | sed 's/Local time zone must be set--see zic manual page/FCTY/' | "${mysql[@]}" mysql
fi

For some reason this code dies but it doesn't log that it died. From that point on the rest of the script does not execute, none of your sql is ever executed and while the database is running, various things that should have happened don't (like setting a root password).

Obviously setting MYSQL_INITDB_SKIP_TZINFO: "yes" in your docker-compose in the environment section "fixes" it. I think this is an important block to have, so I don't think that's a solution.

[ko1eda]

This is happening to me exactly. Mysql container runs completely fine on my windows local environment but when I run it on the production linux server using docker-compose it will not load the script inside docker-entrypoint-initdb.d.

Comparing the logs from my local machine and from the server I noticed two main differences,

Production Server

Version: '5.7.24'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server (GPL)
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.
ERROR 1064 (42000) at line 5: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'root'}')' at line 1

2018-12-04T20:24:08.031556Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2018-12-04T20:24:08.031615Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
2018-12-04T20:24:08.192156Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-12-04T20:24:08.192181Z 0 [Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.

Windows local machine

2018-12-04T19:29:16.104754Z 0 [Note] mysqld: ready for connections.
Version: '5.7.23'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  MySQL Community Server (GPL)
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.
2018-12-04T19:29:19.118430Z 4 [Warning] 'user' entry 'root@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118472Z 4 [Warning] 'user' entry 'mysql.session@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118480Z 4 [Warning] 'user' entry 'mysql.sys@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118673Z 4 [Warning] 'db' entry 'performance_schema mysql.session@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118701Z 4 [Warning] 'db' entry 'sys mysql.sys@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118711Z 4 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118745Z 4 [Warning] 'tables_priv' entry 'user mysql.session@localhost' ignored in --skip-name-resolve mode.
2018-12-04T19:29:19.118780Z 4 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.

/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/create-db.sql

IN the prod server, it's saying there is an error in the sql syntax but I have no idea what it is referring to. I've used this exact setup on another server and it worked fine. I've tried changing the line endings on the script. I've checked the permissions they all seem to be fine. The script is physically copied into the container. I'm bashing my head against the wall here.

This is the dockerfile that builds the container

FROM mysql:5.7

#####################################
# Set Timezone
#####################################

ARG TZ=UTC
ENV TZ=America/New_York
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && chown -R mysql:root /var/lib/mysql/

COPY my.cnf /etc/mysql/conf.d/my.cnf
COPY create-db.sql /docker-entrypoint-initdb.d/create-db.sql

EXPOSE 3306

CMD ["mysqld"]

[mindreader]

I'll say I tried it again today with basically the exact same dockerfile and it worked fine. So it is intermittent somehow.

[ko1eda]

Ok so I think I figured out the issue on my end, finally. I had a .env file set to be used with my docker-compose file and inside that .env file I had all the environment variables set for the mysql container, however I had them all set with "" quotations marks. I believe this was what was giving me the SQL syntax error in the above post.

.env

APP_MOUNT=/srv/app/test-app/

MYSQL_ROOT_PASSWORD="root"

MYSQL_DATABASE="test_db"
MYSQL_USER="test_user"
MYSQL_PASSWORD="password"

I removed the quotation marks and everything seems to be working, I seriously hate this profession sometimes. Its always the simplest things.

working .env

APP_MOUNT=/srv/app/test-app/

MYSQL_ROOT_PASSWORD=root

MYSQL_DATABASE=test_db
MYSQL_USER=test_user
MYSQL_PASSWORD=password

I haven't tried loading a .sql file yet, but that's next. I believe it should work now.

[damianfabian]

After hours of trying to fix this problem, I found that if you use from your DockerCompose a volume to persist the data. If you want the docker-entrypoint-initdb.d to install your databases, you will need to remove the files from your volume in order to make this condition true.
if [ ! -d "$DATADIR/mysql" ]; then
which is basically the condition that will prevent the code of importing to be executed.
I hope this help someone to save hours of time.

[onigirisan]

this fix my problem，hope useful to you

[mvladk]

After hours of trying to fix this problem, I found that if you use from your DockerCompose a volume to persist the data. If you want the docker-entrypoint-initdb.d to install your databases, you will need to remove the files from your volume in order to make this condition true.
if [ ! -d "$DATADIR/mysql" ]; then
which is basically the condition that will prevent the code of importing to be executed.
I hope this help someone to save hours of time.

Solved the problem for me

[myersr]

Slightly embarrassing but wanted to post user error that I ran into incase it helped others here. I worked through this thread for several hours before I thought to view the DB as root.

docker-entrypoint-initdb.d was successfully loading my old db dump under the old schema name instead of the new schema name like I thought it would(inheriting the $MYSQL_DATABASE). I couldn't see the new schema because I was viewing the DB as my new role and not root.

My issue stemmed from running my dump with

• mysqldump --user=... --password=... --routines --triggers --databases OLDDB > devDump.sql
  which saved the old schema info.
• mysqldump --user=... --password=... --routines --triggers OLDDB > devDump.sql
  Removing --databases didn't dump the schema info.

Removing the schema info from the dump loaded the dump file successfully and I was able to view it as my added user.

[eldadfux]

I had the exact same issue and solved it by making sure my mariadb container (version: 10.4) data volume is empty from any files or directories when I create the container from scratch.

This is my docker compose file:

  mariadb:
    image: mariadb:10.4
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ********
    volumes:
    - ./storage/db:/var/lib/mysql:rw
    - ./app/db/SQL:/docker-entrypoint-initdb.d/:rw
    ports:
    - 3306:3306/tcp

For me I just had to make sure this path: './storage/db' is empty from files. Please notice that the directory has to exists but be empty.

[mbtronics]

Same issue here!

• behavior is intermittent (works very occasionally with the same docker-compose file)
• MYSQL_INITDB_SKIP_TZINFO: "yes" fixes it
• without that, the container stops with "Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it."

[geschke]

@mbtronics The same here. Thanks for your workaround, so when I add the environment variable, it runs again, but I think this has to be fixed.
The 10.1 version is ok, but with 10.3 and 10.4 it does not work, even when I try the simplest example of running a MariaDB container according to the Dockerhub description text.

I can provide logs, if needed.

Kind regards,
Ralf

[raullaasner]

@mbtronics This is the only solution that works for me. I spent a full day trying to figure this out. Thanks a lot!

[ivesdebruycker]

@mbtronics in my experience, the containers doesn't stop, it just takes a very long time to load the timezone info (+6 min.). It eventually comes trough and finishes the initialization.

Btw, it's this command in docker-entrypoint.sh that's taking so long:

mysql_tzinfo_to_sql /usr/share/zoneinfo \
			| sed 's/Local time zone must be set--see zic manual page/FCTY/' \
			| docker_process_sql --dont-use-mysql-root-password --database=mysql

[Tum4ik]

Same issue here!

• behavior is intermittent (works very occasionally with the same docker-compose file)
• MYSQL_INITDB_SKIP_TZINFO: "yes" fixes it
• without that, the container stops with "Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it."

This is the best solution.

[yosifkit]

Closing old issue since it seems like it was resolved (permissions?). Please open a new issue with lots details so we can reproduce the error.

For those who fixed their problem by adding MYSQL_INITDB_SKIP_TZINFO=1, then that is most likely just #262.

[dominusbelial]

adding MYSQL_INITDB_SKIP_TZINFO=1 to my k3s mariadb deployment fixed the issue for me!! my dockerfile had the following... COPY backup.sql /docker-entrypoint-initdb.d script ran to some portion or didn't work at all! so i was getting different kinds of error.