Starting Xserver in Docker Ubuntu container

Question

I have minimal Ubuntu installation in my container and I want to have Xserver running. I need XServer, because my app requires meshlabserver, which itself needs Xserver.

I installed xserver-xorg and all other packages, but when I try to start X in container via

/usr/bin/X :0

it says:

Fatal server error:
(EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

What am I doing wrong? How do I start X server?

UPDATE:

related question: Host screen turns off when I start X server in docker container

Solution

In my case it works nicely when I start container in privileged mode:

docker run --privileged

So XServer gets access to some devices from host (including /dev/tty0).

In general case it is a bad idea to run container in privileged mode, but in my case it's okay. To avoid using --privileged you can also try --device option of docker run command.

Comments

[Andreas Steffan]

Do you need a real display? If not, Xvfb may be enough for your purpose. Does the XServer have to run in the container? You may (re) use one running on the host.

[Aleksei Petrenko]

Hmm... I don't really know what is Xvfb. I don't need actual graphical output from apps, meshlabserver just fails to start when Xserver is not running with the following output: meshlabserver: cannot connect to X server. Can I 'emulate' X server by using Xvfb? I don't really need to connect to some external Xserver on host, because I don't need that Xserver anywhere outside the container.

[Aleksei Petrenko]

Turns out xvfb is not working (at least now). I get a number of errors in my app: libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast OpenCV Error: Assertion failed (fbConfigs != 0) in createWindowlessOpenGLContext

[Andreas Steffan]

Your app seems to require openGL and there seems to be a problem with OpenGL and Xvfb (and other X Servers as well). You might want to google for "failed to load driver: swrast". Not sure whether this can be fixed easily. Otherwise, your only option may be to use the hosts X Server - assuming it supports the features demanded by the app.

[Aleksei Petrenko]

Thanks, Andreas. I am using docker in MacOSX with boot2docker, so I have Virtual Box VM on Mac and docker is running inside this VM. There are so many layers of virtualization that I'm really confused. Obviously I have only emulated VirtualBox graphics inside that container, but I installed Mesa software graphics - the same configuration worked in VMWare VM...

[Aleksei Petrenko]

I really don't want to use host XServer, because I'll use this container on many hosts. One possible option is to create container Specifically for XServer, but that does not significantly simplify the things.

[Aleksei Petrenko]

Also found this project: github.com/rogaha/docker-desktop/blob/master/Dockerfile

[Aleksei Petrenko]

Managed to get more information about swrast problem: libGL: screen 0 does not appear to be DRI3 capable libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory.

[datenwolf]

@AlexPetrenko: Apparently the Mesa build you have there doesn't try softpipe first. I think the most straightforward thing would be, to build a custom Mesa variant that has only softpipe support and install that on the system.

[WineSoaked]

I think the prevailing wisdom is that if you do use privileged mode, you should do it only with software that you implicitly trust or have built yourself. And make sure the docker server is only using Unix sockets and not HTTP for its API.

[Aleksei Petrenko]

I built this container myself (except XServer of course), so, yes, I trust it.

[WineSoaked]

The comment was more for those who follow after and read up on this answer. I don't begrudge you your ability to choose to do use Docker how you like, but security is something that can be easily compromised and so cautioning those who look at your answer and don't understand the implications can lead to misery. Just trying to help.