在Docker容器中运行Xephyr
我试图在Docker容器中运行嵌套的X-server Xephyr，直接访问X11套接字，但是我收到了我目前不明白的奇怪的graphics错误。
Dockerfile的内容正好
FROM ubuntu:14.04 RUN apt-get update RUN apt-get install -qqy xserver-xephyr # Clean up APT when done. RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
与之搭build
sudo docker build -t xephyrtest .
并运行它
sudo docker run -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix xephyrtest Xephyr :1
输出以下内容：
Xephyr unable to use SHM XImages Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension DRI3 Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension GLX [dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unscaled, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/Type1, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not init font path element /usr/share/fonts/X11/75dpi, removing from list!
在这里，第一行Xephyr unable to use SHM XImages似乎是最重要的，因为它没有显示在Xephyr工作正常的主机上。
虽然Xephyr窗口popup，但使用:1显示的应用程序显示奇怪的毛刺。 例如DISPLAY=:1 gedit看起来像这样（当鼠标在窗口内移动时输出变化很快）：
SHM XImages是什么意思，我怎样才能解决它在一个容器内的不可用性？
事实certificate，自Docker 1.5使用该命令以来，在Docker容器中运行Xephyr实际上非常简单
sudo docker run -e DISPLAY -v /tmp:/tmp --ipc=host --pid=host xephyrtest Xephyr :1
另外两个参数是
-
--ipc=host允许容器使用与主机相同的IPC名称空间，因此也可以访问相同的共享内存段 -
--pid=host让容器看到（和修改）主机的进程。 这是必要的，因为X服务器端口locking是通过/tmp/.Xi-locklocking文件（replace为您的显示端口）完成的，其中包含端口i上运行的X服务器的pid。
您还必须更改-v /tmp/.X11-unix:/tmp/.X11-unix到-v /tmp:/tmp才能访问容器中的X11 unix套接字以外的locking文件。
尽pipe这样做效果不错，但您必须意识到，这两个额外的参数和对主机的/tmp文件夹的访问会授予容器显着特权，这在某些情况下可能会造成安全风险。
使用选项-extension MIT-SHM运行Xephyr以禁用共享内存的使用。 然后你不需要用--ipc=host选项--ipc=host来分解容器隔离。
为了避免--pid=host选项--pid=host ，考虑在主机上运行Xephyr，共享它的X套接字并设置-e DISPLAY=:1 。 仅仅共享套接字文件/tmp/.X11-unix/X1就足够了，不需要共享整个文件夹甚至整个/tmp 。
MIT-SHM扩展是一种允许在客户机和服务器之间（主要）显示图像的更快方式，只要它们在同一台计算机上运行即可。 这是通过创build一个SysV shm共享内存对象来完成的，客户端可以将图像数据写入X服务器并直接显示，而不必通过套接字将图像序列化。
如果Docker容器阻塞了这个，gedit依赖它，我不会感到惊讶。