docker: Fatal Error Unable to create lock file: Bad file descriptor (9)

Question

Trying an example from the "Docker in Action" book.

$docker run -d --name wp2 --link wpdb:mysql -p 80 --read-only wordpress:4

... should have triggered this error ...

    Read-only file system: AH00023: Couldn't create the rewrite-map mutex
(file /var/lock/apache2/rewrite-map.1)”

but it did not. It triggered a file descriptor error ...

$docker logs wp2
WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html
Wed Dec  9 23:15:21 2015 (21): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:21 2015 (30): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:21 2015 (39): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:21 2015 (48): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (62): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (76): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (90): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (104): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (118): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (132): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (146): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (160): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:15:22 2015 (164): Fatal Error Unable to create lock file: Bad file descriptor (9)

The book suggested that we could make this work using volumes like so ...

$docker run -d --name wp3 --link wpdb:mysql -p 80 -v /var/lock/apache2/ -v /var/run/apache2/ --read-only wordpress:4
305e62e18d926a54ac7d1a0fb775f61efdb61486d9d9245933c3b18055bd9856

container "seems" to start ok
but it did not ...

$docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
6bd4d90f594b        mysql:5             "/entrypoint.sh mysql"   21 minutes ago      Up 21 minutes       3306/tcp            wpdb

the logs say this ...

$docker logs wp3
WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html
Wed Dec  9 23:31:57 2015 (22): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:57 2015 (31): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:57 2015 (40): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:57 2015 (49): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:57 2015 (63): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (77): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (91): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (105): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (119): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (133): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (147): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (161): Fatal Error Unable to create lock file: Bad file descriptor (9)
Wed Dec  9 23:31:58 2015 (165): Fatal Error Unable to create lock file: Bad file descriptor (9)

I'm not sure why this is happening. The book I am reading says that this should work. I was not able to find any examples of anyone else who was getting this particular error. Removing the --read-only flag entirely does work.

$docker run -d --name wp3 --link wpdb:mysql -p 80 -v /var/lock/apache2/ -v /var/run/apache2/ wordpress:4
990874c73691c42d3c04aceb19f83a698f90a2f9ddcf1c07fb3cc9b9f1986723

$docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                   NAMES
990874c73691        wordpress:4         "/entrypoint.sh apach"   5 seconds ago       Up 4 seconds        0.0.0.0:32773->80/tcp   wp3
6bd4d90f594b        mysql:5             "/entrypoint.sh mysql"   About an hour ago   Up About an hour    3306/tcp                wpdb

Answer 1

This is similar to @allingeek's solution, but I couldn't get that to work without explicitly allowing access to /tmp:

docker run -d --name wp --read-only -v /run/lock/apache2/ -v /run/apache2/ -v /tmp/ --link wpdb:mysql -p 80 wordpress:4

Without -v /tmp/ I still got the "Bad file descriptor" log output.

Answer 2

The quick fix for this issue is to use an older version of the WordPress image. It seems that they changed their file locking mechanisms between 4.2 and 4.3. So, the commands become:

$docker run -d --name wp2 --link wpdb:mysql -p 80 --read-only wordpress:4.2
$docker run -d --name wp3 --link wpdb:mysql -p 80 -v /var/lock/apache2/ -v /var/run/apache2/ --read-only wordpress:4.2

Going deeper, it looks like the WordPress image changed the locations where it writes these files. To discover the differences I took the following steps:

• Start up a wordpress:4 container without the read-only file system
• Examine the file system changes to the container
• Change the example to create the volumes at the new locations

This analysis ran as follows:

# Create the writable container
$ docker run -d --name wp10 --link wpdb:mysql -p 80 wordpress:4

# Examine the differences
$ docker diff wp10
C /run
C /run/apache2
A /run/apache2/apache2.pid
C /run/lock
C /run/lock/apache2
C /tmp

# Update the example for the new locations
$ docker run -d --name wp15 --read-only -v /run/lock/apache2/ -v /run/apache2/ --link wpdb:mysql -p 80 wordpress:4

As you can see, the image moved the PID and lock files from /var to /run, and added a write dependency on /tmp. Understanding this analysis is important if you are going to translate this tactic to a different example.