I'm having an issue (well, a number of related issues) with containers and volumes. Some of these issues are mentioned elsewhere, but this particular instance is not.

I am running a container to allow execution of a legacy Wordpress Install. As this is on my development system I didn't want to have a separate mysql container, rather just use the mysql container on my host. Therefore I tried runing docker with the following:

docker run -d --name php53 -v /home/sites/example.org/www:/var/www -v /var/run/mysqld/mysqld.sock:/var/run/mysqld/mysqld.sock precise_apache_php53 /usr/sbin/apache2ctl -D FOREGROUND

The issue is with:

-v /var/run/mysqld/mysqld.sock:/var/run/mysqld/mysqld.sock

The purpose being to expose my host mysql server to the container. This worked beautifully, until my development server was rebooted after a power failure. The mysql stopped working.

It seems on reboot that because /var/run/mysqld/mysqld.sock does not exist it's being created by docker even though no container is running (it's also creating it as a directory, but that's a seperate issue: #13121 ).

So, I decided to change the param to

-v /var/run/mysqld:/var/run/mysqld

As /var/run/mysqld is persistent over reboots. However when I do this, having stopped the container before reboot, it appears that mysql still cannot create the socket file in that directory even though the permissions for the directory are correct. I have to issue a

docker rm php53

command before I reboot to stop docker from creating (or taking control of) /var/run/mysqld

This is problematic as I don't believe docker should be doing anything on my local filesystem until I run a container, and the container is not run automatically at boot.

docker version
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64

docker info
Containers: 29
Images: 72
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 130
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-38-generic
Operating System: Ubuntu 14.10
CPUs: 8
Total Memory: 15.64 GiB
Name: tattve
ID: EKU2:ETU7:MEQA:TLLN:ZJEU:IFDP:36QJ:JLXM:AE66:ZRSG:EMCC:3FZU
WARNING: No swap limit support

uname -a
Linux tattve 3.16.0-38-generic #52-Ubuntu SMP Thu May 7 10:51:21 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Environment
Physical ubuntu 14.10

How Reproducible
I've been able to reproduce the issue with a number of different images running as containers, over numerous reboots. I tracked the issue down to docker by uninstalling it and the issue went away. Upon re-install it started again (presumably because container info was kept through the uninstall)

Steps to Reproduce
On Ubuntu 14.10 or 14.04 with mysql installed from distro .deb files,default configuration

1. docker run --name bugtest x-v /var/run/mysqld/:/var/run/mysqld/ hello_world
2. mysql to access the mysql client, will connect to server (though user/password will be needed)
3. sudo reboot
4. Upon reboot mysqld will not have started due to the issues with /var/run/mysql
   5 mysql will return an error could not connect via /var/run/mysqld/mysqld.sock
5. docker rm bugtest
6. reboot
7. Upon reboot mysqld will have started, mysql will be able to connect

Additional Info

Whilst I'm reporting this issue with mysql as example, I'm simply using that to illustrate a point. The point being that docker seems to be stopping host applications from properly accessing directories which are mapped as volumes, and creating some connection to those directories even when no container is running. I'm not familar enough with Linux Containers to know, but the problem may well be there, rather than docker itself.