Error on mysql startup with --initialize-insecure

[luhkevin]

I was running mysql:5.7 with volume mounts and encountered this error:

2017-04-08T00:44:56.022067Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2017-04-08T00:44:56.022080Z 0 [ERROR] Aborting

I see that we pass the --initialize-insecure flag in the entrypoint, but the conditions for "initialization" are if $DATADIR/mysql is empty: https://github.com/docker-library/mysql/blob/master/5.7/docker-entrypoint.sh#L80

According to this reference, --initialize-insecure will fail if the data directory is nonempty.

So wouldn't this create a race condition if I exit mysql during the initialization process, before the mysql directory has a chance to be created?

[ltangvald]

We don't really know a surefire way to make it robust, but there may be cases where the datadir is not empty and the initialize can succeed (files starting with . or directories the user explicitly set with --ignore-db-dir, while if datadir/mysql (the system tables) is missing, mysql can't be expected to work.
The error message from the server explains the issue fairly well, I think

[luhkevin]

Yeah, I think the files that were in the directory were ibdata1 or ib_logfile.
Don't see --ignore-db-dir passed anywhere.

[qdequippe]

I have exactly the same problem, @luhkevin did you find a way to fix it?

[tianon]

I think unless we have a reliable way to reproduce this, there's not much more we can do to help -- this does indeed sound like a previous initialization which failed, causing subsequent runs to also fail. Since we can't reproduce, I'm going to close, but if a reliable reproducer can be found, a new detailed issue would be appreciated! Thanks!

[ghost]

Facing the same problem here pls could any one explain the solution neatly

[ltangvald]

@Jumaev: When the container starts, if /var/lib/mysql/mysql does not exist, mysqld --initialize-insecure will be executed. --initialize requires /var/lib/mysql to be empty (but can be configured to ignore specific files).

If you're seeing this issue, presumably you're mounting /var/lib/mysql to the host, with something like
-v /somepath/mysqldata:/var/lib/mysql
For this to work, /somepath/mysqldata/ must either contain a functional database, or be completely empty.

[kuhnroyal]

I am running into this after another error on the first start. The mounted data directory is empty on the first start, but it fails. On the 2nd start this error occurs.

First start:

Attaching to foo_server_mysql
foo_server_mysql  | Initializing database
foo_server_mysql  | /usr/local/bin/docker-entrypoint.sh: line 200:    34 Killed                  "$@" --initialize-insecure

Second start:

foo_server_mysql  | Initializing database
foo_server_mysql  | 2018-04-27T11:17:43.760965Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
foo_server_mysql  | 2018-04-27T11:17:43.761019Z 0 [ERROR] Aborting

I am interested in solving the first error, the second is just a result of the first. The data directory is completely empty before the first start.

EDIT:
I actually just found a workaround to my problem, I am not sure why this is happening...
I am using docker-compose. If I mount the host volume with a relative path, the error occurs. If I mount it with absolute path, it works.

[tianon]

Looks like it ran out of memory; does your system have enough available for MySQL?

[kuhnroyal]

@tianon See my edit, it had nothing to do with memory, really weird behavior, could be something docker-compose specific.

[tianon]

Ah, are you on Docker for Mac, Docker for Windows, or Docker Toolbox? (if so, it could be #99 and/or changes in MySQL that no longer work on the shared folders)

[kuhnroyal]

No, just a normal folder in Ubuntu, nothing shared or the like.