How to run a GUI app in docker?

I have a docker container running with O2 built in it. I want to run a stuff with DPL but it quits if there is no GUI (it is a DPL bug). How to have GUIs from within docker ?

Ha. Nice catch. That’s quite an open point, and definitely one we want to address.

The short answer is: there is no easy way to do it, this is why I did not add anything to the doc to this respect.

The quick-and-dirty solution is: you should install sshd inside the container, then connect not via docker exec but via ssh -X. Can you give it a try?

(The DPL bug should be fixed in any case, but that’s a separate topic.)

If we’re talking about X11 traffic, then the following shell functions might help. Not pretty (and not fast) but it works (at least it was at some point, can’t test it again right now)

dxquartz_if_not_running () {
        v_nolisten_tcp=$(defaults read org.macosforge.xquartz.X11 nolisten_tcp)
        v_xquartz_app=$(defaults read org.macosforge.xquartz.X11 app_to_run)
        if (( $v_nolisten_tcp == 1 ))
                defaults write org.macosforge.xquartz.X11 nolisten_tcp 0
        if [ $v_xquartz_app != "/usr/bin/true" ]
                defaults write org.macosforge.xquartz.X11 app_to_run /usr/bin/true
        if [[ "$(launchctl list | grep startx | cut -c 1)" == "-" ]]
                open -a XQuartz
                sleep 2

dgetmyip () {
        ip route get | head -1 | cut -d' ' -f8

docker_run_withX11 () {
        case "$OSTYPE" in
                (darwin*) dxquartz_if_not_running ;;
        case "$OSTYPE" in
                (darwin*) xhost +$(dgetmyip)
                        docker run -e DISPLAY=$(dgetmyip):0 -v /tmp/.X11-unix:/tmp/.X11-unix -e TZ="Europe/Paris" $@ ;;
                (*) xhost +
                        docker run -e DISPLAY=unix$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v /etc/localtime:/etc/localtime -e TZ="Europe/Paris" $@ ;;

Where you then use docker_run_withX11 instead of docker run in your usual workflow.

I will give it a try, thanks.

Stupid question : I usually use stop and start and run only initially. To run again the docker container, shouldn’t I first rm the container ? do I lose all that was installed and done in it ?

Very good point.

My usual workflow is indeed actually a bit different from Dario’s doc. I prepare an image (with all the requisites installed, i.e. all yum stuff done), and then use that image to run containers (which I usually dispose after I’m done). And I don’t loose anything as the code is on my mac, the build artifacts in a volume (or on the mac, in Dario’s workflow) and the system in the image.

So I usually don’t start and stop containers but run and destroy. My X11 “trick” indeed most probably does not work in a start and stop (possibly separated by days) case.

Hi, so - I also tend to prepare images. Instead of running the container, customizing it & saving, I use a Dockerfile and build it.

I was actually thinking - since Docker Hub automatically builds your Dockerfiles, and since our installation instructions are pretty linear, we can just provide Docker containers which are nothing but the base, say, centos:7 with the installation instructions applied.

Would you like our containers to be provided like this? (See, a chance to test Discourse polls.)

  • Yes
  • No

0 voters

@laphecet your X11 solution looks smart, and it even appears it runs both on Linux and macOS. Is it stable, robust enough? Let’s hear from @bvonhall’s experience maybe :wink:

1 Like

@dberzano concerning the “robustness” of my “solution” : I’ve put it in place at a time (about 1.5 years ago or so) I played with Docker for Amore (
But at that time I had an Arch Linux VM where I tested things in a Linux world. Don’t use that VM any longer though, so I won’t bet on the linux part of those functions…