Some days ago the startup process of the X server in my Debian 8 box broke. I'm unsure of what caused this situation, but it probably was either an apt-get upgrade or a rolled back attempt to install Nvidia drivers.
After every reboot /var/log/Xorg.0.log shows the following traces:
[ 60.603] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed [ 60.603] _XSERVTransMakeAllCOTSServerListeners: server already running [ 60.603] (EE) Fatal server error: [ 60.603] (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) [ 60.603] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 60.603] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 60.603] (EE) [ 60.603] (EE) Server terminated with error (1). Closing log file.
The server is not running, but /tmp/.X11-unix/X0 exists and is a directory, instead of a socket. If I log in as root and execute
rmdir /tmp/.X11-unix/X0 ; service kdm restart
then the X server starts without problems.
Any idea on what might be going on and how to fix this problem so the X server can start without user intervention?
find commands didn't return any result (no output at all):
find /etc /var /usr -type f -print0 | xargs -0 grep X11-unix | grep mkdir find / -mount -path /dev -prune -o -path /proc -prune -o -type f -print0 | xargs -0 grep X11-unix | grep mkdir
So I added the
-a exit,always -S all -F dir=/tmp/.X11-unix rule to
/etc/audit.rules, which produced the following traces:
type=SYSCALL msg=audit(1495391670.743:93): arch=c000003e syscall=83 success=yes exit=0 a0=c2082a2420 a1=1ed a2=0 a3=0 items=2 ppid=1 pid=926 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="docker" exe="/usr/bin/docker" key=(null) type=CWD msg=audit(1495391670.743:93): cwd="/" type=PATH msg=audit(1495391670.743:93): item=0 name="/tmp/.X11-unix/" inode=48365573 dev=fe:02 mode=041777 ouid=0 ogid=0 rdev=00:00 nametype=PARENT type=PATH msg=audit(1495391670.743:93): item=1 name="/tmp/.X11-unix/X0" inode=48365588 dev=fe:02 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE type=PROCTITLE msg=audit(1495391670.743:93): proctitle=2F7573722F62696E2F646F636B6572002D64002D480066643A2F2F
A successful syscall 83 is a successful
mkdir, isn't it? This question has become a Docker issue. In the past weeks I've started using
-volume /tmp/.X11-unix:/tmp/.X11-unix in my containers to dockerize X11 applications. I don't understand, however, why it is creating the
/tmp/.X11-unix/X0 directory, taking into account that I haven't specified the
X0 part in the path and also that those containers are started once the desktop is loaded, not before.
Is is possible that Docker is trying to restore the state of previously run containers? Anyone can provide any hint on how to prevent this?