Mysql root user is not initialized #216
Comments
|
Is there already a database (or any files or directories) in .volumes/mysql? If so, database init will be skipped, and that includes execution of the scripts in docker-entrypoint-initdb.d Also, the scripts will be executed at the end of database init, so the script for fixing the permissions will be run after the first database startup, which might create an inconsistent setup for things like setting the default storage engine. A better solution might be to set the permission in Dockerfile. |
|
The problem is that the container exits with code 1 when I tried to change the permissions to 644 ! But I tried to build the container from scratch after removing the volumes/mysql folder, and I have new evidences of the problem : Ty for your quick answer :) ! |
|
@Kern046, it looks like you still need to add a chmod to the Dockerfile for your |
|
@yosifkit, my problem actually was that I was unable to make the container run with a My solution was to give up Docker Toolbox and Docker Machine and create a VM with Vagrant. I do not have permissions problems anymore with Ubuntu Xenial (my VM OS), but the scripts in /docker-entrypoint-initdb.d are still not executed, root stills have empty password, and no host is able to connect except localhost (event 127.0.0.1 is forbidden) |
|
If the container fails to start, then it is not a problem with the chown, but a problem with the config itself. The problem is that our entrypoint script does a mysql/5.7/docker-entrypoint.sh Line 27 in de740a4 So to find the problem, I copied your cnf file and ran the following: $ docker run -it --rm -v $PWD/my.cnf:/etc/mysql/conf.d/my.cnf --name mysql -e MYSQL_ROOT_PASSWORD=12345 mysql:5.7 bash
root@fd0ebe7e491c:/# mysqld --verbose --help > /dev/null
2016-09-30T18:06:45.828087Z 0 [ERROR] unknown variable 'key_buffer=16M'
2016-09-30T18:06:45.829979Z 0 [ERROR] Aborting
|
|
I made #218 to print the errors so that you don't get a stopped container with no output. |
|
Ah right, I didn't spot that. |
|
Hello there ! Thanks for the answers ! I updated the configuration file but it still does not work ! I tested also your useful command to detect any other error, but it does not produce any output ! I tried to just launch the I've read the mentionned Security section and tried to launch With docker-compose, my container stills start well, but without any password to my root user and without executing my scripts. Thank you both for your answers :) ! |
|
I think you're missing the mysqld --initialize run that the container does when started with compose or default docker run command. |
|
Indeed ! It starts fine. I think I'm coming to get it. Reviewing the Dockerfile of the image, I notice the following piece of code : for i in {30..0}; do
if echo 'SELECT 1' | "${mysql[@]}" &> /dev/null; then
break
fi
echo 'MySQL init process in progress...'
sleep 1
done
if [ "$i" = 0 ]; then
echo >&2 'MySQL init process failed.'
exit 1
fiThis is exactly what is coming in my logs when I launch the container the first time after removing When I launched it the second time I haven't the initialization part and everything seemed to work, but the code modifying the root user is after the initialization code which failed. Everything is coming clear, unless the cause of the error :p ! We're getting close ! Thank for your patience ! EDIT : I don't know if I said it earlier, but the visible problem is that mysqld hasn't any binded port when initializing, maybe iet's a clue. |
|
Any success on this? How to resolve the issue? |
|
@RCooLeR None for the moment, I'd like to get some time to try to solve it myselfn I hope in the next few days. Did you experience the same issue ? |
|
Yes. I rebuild my docker with mysql/mysql-server but I think all thing is in timing... It just doesn't create/update users in time. I have also noticed another issue with docker-compose |
|
In fact, I think the main clue is here : Why port 0 ? Why the port is not the configured one ? It seems quite logic that the check fails with this. The thing is that the second time that I launch the container, the port is set correctly, but due to the fact that there are files in the If we succeed to fix the port 0 the first time after the container building, I think we would be done with that issue. |
|
The This first "extra" start of mysql is only done when the mysql datadir does not have a When it runs correctly I get both of these lines in the output: Version: '5.7.15' socket: '/var/run/mysqld/mysqld.sock' port: 0 MySQL Community Server (GPL)
Version: '5.7.15' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL) |
|
Ok, I understand. The thing is, I removed my configuration file to try to init the container without it, and I have the same issue. I do not understand why the init fails in both cases. I'm still searching the possible cause. |
|
I FOUND IT :D !!!! It is rather mysterious to me, but it was the environment variable MYSQL_HOST which was the cause of this m*ss. In my docker-compose.yml, I just left it empty, as suggested in #82 ! I do not understand at all why I cannot set this variable, but in fact the problem is solved, everything is working at least. I'm in paradise. I hope I didn't waste too much of your time. I close the issue ! Thank you all :D ! |
|
Hey. Can you add example of correct config pls? |
|
Yes I can :D ! I was just testing if I could set a value to MYSQL_HOST and the answer iiiiis... YES ! So there is my new docker-compose.yml : mysql:
container_name: my_mysql
build: mysql
environment:
- MYSQL_DATABASES=my_database
- MYSQL_ROOT_PASSWORD=password
- MYSQL_HOST=localhost
- MYSQL_PORT=33306
- MYSQL_USER=my_user
- MYSQL_PASSWORD=my_password
- MYSQL_LOYALTY_DATABASE=my_database
ports:
# MySQL
- "33306:3306"
volumes:
# Mysql
- "./volumes/mysql:/var/lib/mysql"I hope I can help you :) ! |
|
I think the cause is we start mysqld with --skip-networking, and when it tries to connect to 127.0.0.1 it is denied while localhost works. Simplest fix might be to add a -hlocalhost to the client call in the entrypoint script, which will make it ignore the MYSQL_HOST environment variable for that call. |
|
Actually, even without --skip-networking it will fail, though with «access denied» instead of «can't connect» |
|
We could maybe also change this to store stderr output so that if the init times out, the error from the last attempt can be passed to the user: https://github.com/docker-library/mysql/blob/master/5.7/docker-entrypoint.sh#L73 |
|
It's true that the failure errors are not talkative ones, but I do not know which part is related to this repository, and which part is due to MySQL itself. |
|
MySQL's behavior here is by design; When the database is initialized, the user 'root'@'localhost' will be created, and can only be logged in through the host "localhost", which mysql treats as a local unix socket connection rather than going through the networking interface. So for a fresh database you can't log in as 'root'@'127.0.0.1', only 'root'@'localhost' So you get two problems when trying to start a fresh container with MYSQL_HOST=127.0.0.1:
|
Hello there !
I am facing some kind of problem with the 5.7 image. The short description is that the container is set up properly, but it is impossible to connect with the root user. My suggestion is that the root password is not initialized properly.
I am using docker-toolbox with Windows (quite sad about it but due to VPN and company group strategies it is quite hard to setup a Unix environment here) and I think Windows permissions are the problem.
I copy here my files :
docker-compose.yml
mysql/Dockerfile
mysql/conf.d/custom.cnf
docker-entrypoint-initdb.d/config.sh
docker-entrypoint-initdb.d/databases.sh
I tried to change the permissions of
custom.cnfbecause it is created in mode 666 and mysql ignores it with the message World writeable config file "custom.cnf" has been ignored. But my script is never executed, nor thedatabases.shscript which would fail anyway because the root user is not available.I think the reason is that mysql cannot create the root user when failing at reading the config file, but when I removed the
custom.cnffile, I had the following logs :I put in evidence the file permissions problems.
In the Dockerfile, I tried to run chmod 644, but after investigation, it is impossible with docker toolbox to modify the "o" permissions. I can do
chmod u=rw,g=rbut notu=rw,go=ror evena=r. I tried several combinations before concluding that it is impossible with docker toolbox on windows to change the "o" permissions during the building. I do not know if I have to do an issue in Docker Machine repository or Toolbox.I would be glad if you can help me, that would avoid a Vagrant box on my Windows, which would be sad for me and my team :D !
Thanks a lot, and have a nice day !
The text was updated successfully, but these errors were encountered: