X windows crashes on startup if docker container set to auto restart

I am running docker version 1.5.0 on centos 6.6 under vmware workstation.

I am running a wordpress container, and everything works fine until I reboot my vmware vm.

If I set the docker container to --restart=always, then Xwindows crashes on startup with these errors:

36.541] (--) Depth 24 pixmap format is 32 bpp

[ 36.541] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
[ 36.541] (II) vmware(0): Initialized VMware Xinerama extension.
[ 36.541] (II) vmware(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0
[ 36.541] (EE) vmware(0): Unable to map mmio BAR. Read-only file system (30)
[ 36.665] (EE) vmware(0): Unable to map frame buffer BAR. Read-only file system (30)
[ 36.665] (EE)
[ 36.665] (EE) Backtrace:
[ 36.665] (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x51) [0x5aae11]
[ 36.665] (EE) 1: /usr/bin/Xorg (0x400000+0x1af209) [0x5af209]
[ 36.665] (EE) 2: /lib64/libpthread.so.0 (0x369a000000+0xf710) [0x369a00f710]
[ 36.665] (EE) 3: /lib64/libc.so.6 (0x3699c00000+0x8431b) [0x3699c8431b]
[ 36.665] (EE) 4: /usr/lib64/xorg/modules/drivers/vmware_drv.so (0x7f69e0fa1000+0x5b93) [0x7f69e0fa6b93]
[ 36.665] (EE) 5: /usr/bin/Xorg (AddScreen+0xa9) [0x432579]
[ 36.665] (EE) 6: /usr/bin/Xorg (InitOutput+0x3c9) [0x47df19]
[ 36.665] (EE) 7: /usr/bin/Xorg (0x400000+0x3c6b3) [0x43c6b3]
[ 36.665] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3699c1ed5d]
[ 36.665] (EE) 9: /usr/bin/Xorg (0x400000+0x269c9) [0x4269c9]
[ 36.665] (EE)
[ 36.665] (EE) Segmentation fault at address 0x0

If the container is not set to auto restart, X starts fine.

If I set docker to not start up via chkconfig, reboot the machine, and then start docker, the container auto starts.

I tried disabling the VMWare tools and the vmware-tools-thinprint services

Any insight into this would be appreciated.

I have performed a yum update, and this didn’t help.

The obvious thing seems to be to delay the docker container from starting until after X finishes initializing, but since X starts after all the /etc/init.d scripts load, I don’t see how to do that, unless I install something like supervisor.

Thank you

Just to follow up - if the docker service starts, but the container is not set to autorestart, then X starts okay.

I worked around this by hacking the /etc/init.d/docker file:

start() {
[ -x $exec ] || exit 5

if [ $(runlevel|awk ‘{print $NF}’) eq 5 ]
if [ $(ps -eaf|grep Xorg|grep -c -v grep) -eq 0 ]
echo service docker start | at now +1 min >/dev/null
exit 0

If we are at runlevel 5 (X), and X isn’t running yet, then create an at job to try again in a minute.


Thank you very much for your workaround. This was also an issue for me. We are running docker 1.5.0 on Scientific Linux 6.6 under ESXi 5.5. Hopefully this issue is fixed in future versions of docker/CentOS/SL. I re-formatted your script fragment and fixed a small bug:

start() {
    [ -x $exec ] || exit 5

# The code below checks to see if the runlevel is 5. If so, it checks
# to see if X is running yet. If it isn't, then it schedules an at(1)
# job to run in one minute to start docker then.
if [ $(runlevel | awk '{print $NF}') -eq 5 ]; then
    if [ $(ps -eaf | grep Xorg | grep -c -v grep) -eq 0 ]; then
        echo service docker start | at now +1 min >/dev/null
        exit 0

I forgot to post the fix. Thanks. I’d like to know what’s causing this.

I have been experimenting with another virtual machine running exactly the same (as far as I can tell) docker containers as previously with exactly the same docker version. This machine has the stock /etc/init.d/docker file without the workaround from above. Everything works great. Reboots are flawless.

The only thing that might be different is a new kernel version: 2.6.32-504.23.4.el6.x86_64

Coincidentally, I installed this kernel version on the machine with the problem (my prod machine) the very same day that I first noticed it. However, I am not sure if I had that kernel version installed or not when I posted. I am now thinking of removing the workaround from the prod machine’s /etc/init.d/docker file (when I can get access) and trying a few reboots to see what happens…

This issue still persists with docker 1.7.1 and kernel 2.6.32-573.3.1.el6.x86_64.

I think I was misleading myself somehow into believing that everything was working.

Be careful. A yum update docker-io will overwrite /etc/init.d/docker and obliterate the posted workaround. As well, note that the 1.7.1 version of /etc/init.d/docker has some desirable minor improvements in the start function. diff(1) is your friend.

I have the same problem, not only on VMware but also on physical servers (IBM). It is not systematic, on some servers it works without that I can see a difference. Upgrading docker and the kernel does not make a difference (they are all red-hat or centos 6.6).

The work-around is working, I’ll have to leave with it on servers where X is required.

Thanks a lot.


You’re welcome - I’d really like to know what the root cause is - my guess
it’s a race condition of some sort for docker spinning up its virtual