Gzweb won't start on some versions of Ubuntu

[mhl787156]

Cross post of issue https://github.com/StarlingUAS/FenswoodScenario/issues/15

Windows version (docker-compose.windows.yml) works fine on Windows and on Linux. Trying to run the Linux compose file on Ubuntu, I get an endless "Wait for X server" message from the simhost container. Starts off as below.

aeagr@IT034704:~/docker_ws/FenswoodScenario$ docker-compose -f docker-compose.linux.yml up
Creating fenswoodscenario_sitl_1            ... done
Creating fenswoodscenario_ui-example_1      ... done
Creating fenswoodscenario_mavros_1          ... done
Creating fenswoodscenario_simhost_1         ... done
Creating fenswoodscenario_rosbridge-suite_1 ... done
Attaching to fenswoodscenario_simhost_1, fenswoodscenario_ui-example_1, fenswoodscenario_rosbridge-suite_1, fenswoodscenario_mavros_1, fenswoodscenario_sitl_1
simhost_1          | --------------- Start setup_display.sh ----------------------
simhost_1          | Creating virtual display using virtual framebuffer
simhost_1          | Waiting for display to become available
simhost_1          | Wait for X server..
simhost_1          | _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
simhost_1          | _XSERVTransMakeAllCOTSServerListeners: server already running
simhost_1          | (EE) 
simhost_1          | Fatal server error:
simhost_1          | (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) 
sitl_1             | AP_SYSID setting as specified: 1
sitl_1             | AP_SYSID is set to 1
simhost_1          | Wait for X server..
simhost_1          | Wait for X server..

All other containers boot fine but I can never get anything on localhost:8080 and after a while, I get nothing but the simhost messages.

---- Reply:

Ah it seems a couple of people have got this error recently. Oddly enough on our tutorial day it only affected half of the students using Uni laptops. Our advice was to use the docker-compose.windows.yml for now.

@rob-clarke had a quick look on the day but we couldn't figure out what was happening, I will have a quick look at it. I suspect a linux update is causing an X server to automatically start, so when the container starts its own it doesn't work anymore...

Perhaps we should recommend the usage of the windows variant by default, and only use the linux variant if a user wishes to do something with ubuntu native.

[rob-clarke]

IIRC there were some complaints in the log about the port Xvfb was trying to use.

A good direction might be to transition to using (/renaming) the windows version as the standard compose file, then have a *.network-host.yml version for more advanced use, making it clear that the network-host version won't work on Windows.

[rob-clarke]

~Get affected users to check for TCP/6001 in netstat -ln which is the default port for X display 1~ The error messages above talk about UNIX sockets...

The -displayfd option might be useful [source]:

-displayfd fd: specifies a file descriptor in the launching process. Rather than specify a display number, the X server will attempt to listen on successively higher display numbers, and upon finding a free one, will write the port number back on this file descriptor as a newline-terminated string. The -pn option is ignored when using -displayfd.

Maybe something like:

Xvfb -displayfd 3 [other options] 3>/tmp/display
export DISPLAY=:$(cat /tmp/display)

[rob-clarke]

I get the same issue on my machine. When logged in my user is already has DISPLAY=:1 so I imagine the one in the container conflicts. Only an issue when running with --network=host

[rob-clarke]

Fix in PR