mysqld shutsdown.. how to resolve??

[meticulo3366]

laptop computer has about 20 gb of free disk space... not sure what issue is here causing the image to fail to load. but basically there are two problems

(1) The docker image continues to run even though MYSQL failed to start

(2) The docker image claims no diskspace, but there is plenty of diskspace available

db_1 | Initializing database
db_1 | 2015-11-23 15:43:17 0 [Note] /usr/sbin/mysqld (mysqld 5.6.27) starting as process 17 ...
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Using atomics to ref count buffer pool pages
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: The InnoDB memory heap is disabled
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Memory barrier is not used
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Compressed tables use zlib 1.2.8
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Using Linux native AIO
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Using CPU crc32 instructions
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Initializing buffer pool, size = 128.0M
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Completed initialization of buffer pool
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB
db_1 | 2015-11-23 15:43:17 17 [Note] InnoDB: Database physically writes the file full: wait...
db_1 | 2015-11-23 15:43:17 7f1e4d02c7402015-11-23 15:43:17 17 [ERROR] InnoDB: Failure of system call pwrite(). Operating system error number is 28.
db_1 | InnoDB: Error number 28 means 'No space left on device'.
db_1 | InnoDB: Some operating system error numbers are described at
db_1 | InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
db_1 | 2015-11-23 15:43:17 17 [ERROR] InnoDB: Error in creating ./ibdata1: probably out of disk space
db_1 | 2015-11-23 15:43:17 17 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
db_1 | 2015-11-23 15:43:17 17 [ERROR] Plugin 'InnoDB' init function returned error.
db_1 | 2015-11-23 15:43:17 17 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
db_1 | 2015-11-23 15:43:17 17 [ERROR] Unknown/unsupported storage engine: InnoDB
db_1 | 2015-11-23 15:43:17 17 [ERROR] Aborting
db_1 |
db_1 | 2015-11-23 15:43:17 17 [Note] Binlog end
db_1 | 2015-11-23 15:43:17 17 [Note] /usr/sbin/mysqld: Shutdown complete

db:
image: mysql:5.6
ports:
- "3306:3306"
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: yes

[meticulo3366]

any comments on how to fix this issue?

[thaJeztah]

how did you start the container? Did you use a bind-mounted volume?

[meticulo3366]

this is my docker-compose file...

db:
image: mysql:5.6
ports:
- "3306:3306"
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'

[meticulo3366]

i dont use binded mount volume, i want the data wiped every time it turns on, how do i do that and ensure that the mysql container does not crash?

[thaJeztah]

i want the data wiped every time it turns on

well, docker-compose may actually try to preserve the volume that the container uses, unless you remove the container (probably with the -v flag; docker-compose rm -v db)

[lloydwatkin]

I'm seeing this same issue, I start the container using:

sudo docker run --name mysql-dev -e MYSQL_ROOT_PASSWORD=password -d mysql:latest -p 127.0.0.1:3306:3306

After clearing the image completely and rerunning I still see the issue: https://gist.github.com/lloydwatkin/c4f4c8ac1f50c262a20b

This may be related to my system (ubuntu 15.10) crashing - pesky hard drive on the way out. Its used for a development Db so having a clean entry on each start is what I'm after.

[thaJeztah]

@lloydwatkin I spotted some things in your examples;

In your example above, you put the -p 127.0.0.1:3306:3306 _after_ the image name, so it will be passed as an argument to mysqld, not docker run, so I'm not sure that's what you intended to do.

In the _linked_ example (in your gist), you are overriding the image's default command. The initialization steps in the entrypoint script of the image will therefore be skipped. See: https://github.com/docker-library/mysql/blob/ed198ce2e8aa78613c615f20c5c4dd09fa450f66/5.7/docker-entrypoint.sh#L9

[lloydwatkin]

@thaJeztah sorry command was written out incorrectly compared to my scripted startup. I've managed to get around this issue by killing the docker daemon and starting (rather than restarting which made no difference).

[tianon]

I think this is an issue with either the environment or boot2docker/Docker Machine/Toolbox, and not this image. I'd recommend trying the Docker forums or the #docker channel on the Freenode IRC network for further help diagnosing. Thanks!

[lloydwatkin]

Yes this eventually turned out to be an issue with the docker daemon (long
forgotten about sorry!). Often a kill and a restart would solve. Later
kernel and docker upgrades means the problem hasn't happened in forever.

On 29 Aug 2016 7:32 p.m., "Tianon Gravi" [email protected] wrote:

Closed #122 https://github.com/docker-library/mysql/issues/122.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker-library/mysql/issues/122#event-771088626, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQlBuP1sn_fSR0K7tozHYKsjPW7NKaBks5qkyWrgaJpZM4GnoNF
.

[lloydwatkin]

Yes this eventually turned out to be an issue with the docker daemon (long
forgotten about sorry!). Often a kill and a restart would solve. Later
kernel and docker upgrades means the problem hasn't happened in forever.

On 29 Aug 2016 7:32 p.m., "Tianon Gravi" [email protected] wrote:

Closed #122 https://github.com/docker-library/mysql/issues/122.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker-library/mysql/issues/122#event-771088626, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAQlBuP1sn_fSR0K7tozHYKsjPW7NKaBks5qkyWrgaJpZM4GnoNF
.

[albert3010]

@thaJeztah thanks for your inputs I also had the same issue.

So the problem might be we are not removing the created containers with -v flag. As a result dangling volumes are created every time and disk space got full.
Solution That worked for me:
I removed all such dangling volumes with the steps

1. docker volume ls -f dangling=true ( see how many files are there)
2. docker volume rm docker volume ls -q -f dangling=true

And also next time use -v flag ex: docker rm -v id.
Hope this helps. thanks

[tianon]

@albert3010 a simpler way to delete dangling images in recent Docker versions is docker volume prune :+1: