X não inicia porque /tmp/.X11-unix/X0 é um diretório

2

Alguns dias atrás, o processo de inicialização do servidor X na minha máquina Debian 8 quebrou. Não tenho certeza do que causou essa situação, mas provavelmente foi uma atualização do apt-get ou uma tentativa de instalar os drivers da Nvidia.

Após cada reinicialização, o /var/log/Xorg.0.log mostra os seguintes rastreamentos:

[    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.

O servidor não está em execução, mas /tmp/.X11-unix/X0 existe e é um diretório, em vez de um soquete. Se eu logar como root e executar

rmdir /tmp/.X11-unix/X0 ; service kdm restart

então o servidor X é iniciado sem problemas.

Alguma ideia do que pode estar acontecendo e como corrigir esse problema para que o servidor X possa ser iniciado sem a intervenção do usuário?

EDIT 1

Os seguintes comandos find não retornaram nenhum resultado (nenhuma saída):

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

Então, adicionei a regra -a exit,always -S all -F dir=/tmp/.X11-unix a /etc/audit.rules , que produziu os seguintes traços:

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

Um syscall 83 de sucesso é um mkdir de sucesso, não é? Esta questão tornou-se um problema do Docker. Nas últimas semanas, comecei a usar -volume /tmp/.X11-unix:/tmp/.X11-unix em meus contêineres para aplicativos dockerize X11. Não entendo, no entanto, por que está criando o diretório /tmp/.X11-unix/X0 , levando em conta que não especifiquei a parte X0 no caminho e também que esses contêineres foram iniciados quando a área de trabalho foi carregada, não antes .

É possível que o Docker esteja tentando restaurar o estado de contêineres executados anteriormente? Alguém pode fornecer alguma sugestão sobre como evitar isso?

    
por Guillermo López Alejos 06.05.2017 / 09:07

0 respostas

Tags