Closed mhl787156 closed 2 years ago
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.
~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)
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
Fix in PR
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.
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.