Open aalexgabi opened 7 years ago
I could also reproduce on a Ubuntu 14.04 with a 4.4 kernel:
% docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 2
Server Version: 17.05.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
apparmor
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.56GiB
Name: loki
ID: FQW3:U4O6:S5I7:JT35:YAPI:OE5P:FT2J:226W:DAVQ:DWUH:MIFE:ETFK
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
@dmcgowan I don't think this is builder specific. If I move the image built in aufs to overlay it has the same problem. Starting container with docker run -v /var/lib/mysql
also works fine(what should be recommended in a case like this).
@tonistiigi - In a downstream issue where I was finding this same behavior on Docker for Mac, I added a /var/lib/mysql
volume and the error went away. (See https://github.com/geerlingguy/drupal-vm/issues/1497).
That's an acceptable fix for me, and it's actually how I set up most projects' MySQL container in a Docker Compose... but until sometime in the past few weeks, I was able to not add that volume and still get MySQL to start up correctly.
@tonistiigi I cannot use a volume because I use Docker for integration tests so I need the data snapshot inside the docker image so that the boot is fast and isolated from other containers. The alternative would be to manually manage MySQL volumes and copy the volume before each run but that would generate a lot of IO and lowering IO usage was the primary reason for using overlay2 in the first place.
The question for me is why this works with aufs and does not work with overlay2 and overlay? Is there any known limitation?
I found the problem.
From the Docker documentation on overlay2:
open(2): OverlayFS only implements a subset of the POSIX standards. This can result in certain OverlayFS operations breaking POSIX standards. One such operation is the copy-up operation. Suppose that your application calls fd1=open("foo", O_RDONLY) and then fd2=open("foo", O_RDWR). In this case, your application expects fd1 and fd2 to refer to the same file. However, due to a copy-up operation that occurs after the second calling to open(2), the descriptors refer to different files. The fd1 continues to reference the file in the image (lowerdir) and the fd2 references the file in the container (upperdir). A workaround for this is to touch the files which causes the copy-up operation to happen. All subsequent open(2) operations regardless of read-only or read-write access mode will be referencing the file in the container (upperdir).
yum is known to be affected unless the yum-plugin-ovl package is installed. If the yum-plugin-ovl package is not available in your distribution such as RHEL/CentOS prior to 6.8 or 7.2, you may need to run touch /var/lib/rpm/* before running yum install. This package implements the touch workaround referenced above for yum.
As pointed in the docs the workaround is to touch
the files used by MySQL:
FROM debian:wheezy
RUN apt-get update && apt-get install -y mysql-server-5.5
RUN find /var/lib/mysql -type f -exec touch {} \; && service mysql start
Can somebody add a note in the docs (next to the yum one) that mentions that MySQL is also affected?
Anyone has strace
d this?
Is this an open(2)
issue or rename(2)
one?
For me it works only this way:
cat init.sh
#!/bin/bash
find /var/lib/mysql -type f -exec touch {} \; && service mysql start
tail Dockerfile -n 2
COPY init.sh /tmp/
ENTRYPOINT "/tmp/init.sh" && /bin/bash
The workaround works for me, but it takes quite a while to run on my Windows pc (~4-5 seconds). I'm using a mysql image that is specifically tailored to having super-fast start-up times, and without the touch workaround, it starts up in under a second, but with the fix, it takes over 5!
Is there anything else I can try as an alternative workaround on Windows?
I have also encountered this when I excuted /etc/init.d/mysql start in docker:
190125 16:58:01 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
190125 16:58:01 InnoDB: The InnoDB memory heap is disabled
190125 16:58:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
190125 16:58:01 InnoDB: Compressed tables use zlib 1.2.8
190125 16:58:01 InnoDB: Using Linux native AIO
190125 16:58:01 InnoDB: Initializing buffer pool, size = 128.0M
190125 16:58:01 InnoDB: Completed initialization of buffer pool
190125 16:58:01 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
190125 16:58:01 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
190125 16:58:01 InnoDB: Waiting for the background threads to start
190125 16:58:02 InnoDB: 5.5.58 started; log sequence number 701019810
190125 16:58:02 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
190125 16:58:02 [Note] - '127.0.0.1' resolves to '127.0.0.1';
190125 16:58:02 [Note] Server socket created on IP: '127.0.0.1'.
190125 16:58:02 [ERROR] Fatal error: Can't open and lock privilege tables: Got error 140 from storage engine
190125 17:00:13 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
190125 17:00:13 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Got error 140 from storage engine
190125 17:00:13 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
190125 17:00:13 InnoDB: The InnoDB memory heap is disabled
190125 17:00:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins
190125 17:00:13 InnoDB: Compressed tables use zlib 1.2.8
190125 17:00:13 InnoDB: Using Linux native AIO
190125 17:00:13 InnoDB: Initializing buffer pool, size = 128.0M
190125 17:00:13 InnoDB: Completed initialization of buffer pool
190125 17:00:13 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
190125 17:00:13 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
190125 17:00:13 InnoDB: Waiting for the background threads to start
190125 17:00:14 InnoDB: 5.5.58 started; log sequence number 701019810
190125 17:00:14 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
190125 17:00:14 [Note] - '127.0.0.1' resolves to '127.0.0.1';
190125 17:00:14 [Note] Server socket created on IP: '127.0.0.1'.
190125 17:00:14 [ERROR] Fatal error: Can't open and lock privilege tables: Got error 140 from storage engine
My machine is centos7 and my docker storage engine is overlay2, this is output of docker info:
[root@slave119 ~]# docker info
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 10
Server Version: 1.12.6
Storage Driver: overlay2
Backing Filesystem: xfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.26.2.el7.x86_64
Operating System: NewStart Carrier Grade Server Linux Core 1.3
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 23.37 GiB
Name: slave119
ID: P3UX:UX3G:HC7E:PW55:NI7L:Q53S:K57X:E4DK:WRXU:MGNO:CRV4:YQRA
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 16
Goroutines: 24
System Time: 2019-01-25T17:15:31.396644054+08:00
EventsListeners: 0
Registry: https://index.docker.io/v1/
Insecure Registries:
0.0.0.0/0
127.0.0.0/8
I found that this problem doesn't happen for me (Ubuntu 18.04) but it does happen for my colleagues that use docker for Mac OS. See the gist below for the output of docker info
on these two systems:
https://gist.github.com/MatrixManAtYrService/77f433e2fa4d6e091d75a8394781be45
Expected behavior
MySQL should start
Actual behavior
MySQL does not start and returns an error:
Steps to reproduce the behavior
Using Dockerfile:
Output:
Interestingly MySQL starts when is started in the same intermediate container: Using Dockerfile:
Output:
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.)
I tried with the Linux 4.9 Kernel from Jessie backports and Linux 4.11 from Liquorix and the problem exists for both.
The problem arises when using overlay2 and overlay. The problem does not arise when using aufs.