VNC Container failed to startup because of missing X11 connection (timing issue) #353
Comments
|
Please make sure that you are using xvfb-server image for x-server
container instead of x-server.
вт, 18 окт. 2022 г., 15:33 Michael Mühlebach ***@***.***>:
… Bug description
When starting a new selenium browser over the moon-ui a new browser pod is
scheduled correctly but the VNC connnection can not be established. We
tested it with edge, chrome and firefox but in the following print outs I
always use the output of chrome.
From our analysis it looks like X11 was started correctly but was ready
after VNC was already started and therefore failed.
Analysis/Experienced Behaviour
According to the output of kubectl the vnc-server was terminated. Output
of oc describe pod chrome-...:
kubectl-describe-chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b.log
<https://github.com/aerokube/moon/files/9810367/kubectl-describe-chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b.log>
I attached the log of the VNC Container but as far as I could see, the log
says that VNC could not be started because of the missing connection to X11:
chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b-vnc-server.log
<https://github.com/aerokube/moon/files/9810204/chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b-vnc-server.log>
The X-Server Container seems to work and verified it with debugging the
VNC Container were I could start VNC correctly. It looks to me like a
timing issue. Here is what I did:
$ oc debug pod/chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b -c vnc-server
Starting pod/chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b-debug ...
Pod IP: ***
If you don't see a command prompt, try pressing enter.
$ x11vnc -xrandr -passwd selenoid -noxrecord -forever -display :0 -shared -rfbport 5900
18/10/2022 12:18:10 passing arg to libvncserver: -passwd
18/10/2022 12:18:10 passing arg to libvncserver: -rfbport
18/10/2022 12:18:10 passing arg to libvncserver: 5900
18/10/2022 12:18:10 x11vnc version: 0.9.16 lastmod: 2019-01-05 pid: 7
18/10/2022 12:18:10 Using X display :0
18/10/2022 12:18:10 rootwin: 0x50d reswin: 0x400001 dpy: 0x79c065a0
...
The VNC desktop is: chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b:0
PORT=5900
Expected Behaviour
There should either be some flag for a startup delay or some type of retry
or startup when x11 ready behaviour.
Additional Context
- OpenShift 4.8.24 (Kubernetes v1.23.5+012e945)
- Moon 2.3.7
- Selenium Browsers:
- microsoft-edge-stable 101.0.1210.39-1
- google-chrome-stable 101.0.4951.54-1
- firefox-mozilla-build 99.0.0-1
—
Reply to this email directly, view it on GitHub
<#353>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23IIN5T65I27OUPRZUDWD2KHXANCNFSM6AAAAAARIBF3VE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@mikevader i.e. |
|
Yes we are using the xvfb-server image as you can see in the describe output. But looking at the checksums, the two images are identical. |
|
I created a workaround which confirmed my suspicion about the timing issue: I wrapped your VNC image with the following container: With this it works. But it is more a hack than something else. I guess it would be a good idea if you add something similar to the official vnc-server image. I can give it a go but I could not find the correct repositories for those images. |
|
@mikevader ok, one more possible solution is trying to use a bit older image: |
|
Any update on this? We seem to run into the same issue with Moon 2.6.7 (we use official images), the vnc server container sometimes (e.g. 1 in 10 runs) exits with: 16/10/2024 11:45:12 passing arg to libvncserver: -passwd 16/10/2024 11:45:12 *************************************** *** x11vnc was unable to open the X DISPLAY: "127.0.0.1:0", it cannot continue. Maybe a simple loop with nslookup for X-server service should be added to the vnc container, since the order of container startup is not guaranteed by Kubernetes, the x-server may start too early (or too late). |
|
Looks like x server did not start, please check x-server container log.
Anyway, try to upgrade to latest 2.7.2 release, there all service container
images have been reworked and contain only needed binaries, also it
dramatically decreased imege size, please check it.
ср, 16 окт. 2024 г., 15:00 bukovjanmic ***@***.***>:
… Any update on this? We seem to run into the same issue with Moon 2.6.7 (we
use official images), the vnc server container sometimes (e.g. 1 in 10
runs) exits with:
16/10/2024 11:45:12 passing arg to libvncserver: -passwd
16/10/2024 11:45:12 passing arg to libvncserver: -rfbport
16/10/2024 11:45:12 passing arg to libvncserver: 5900
16/10/2024 11:45:12 x11vnc version: 0.9.16 lastmod: 2019-01-05 pid: 11
16/10/2024 11:45:12 XOpenDisplay("127.0.0.1:0") failed.
16/10/2024 11:45:12 Trying again with XAUTHLOCALHOSTNAME=localhost ...
16/10/2024 11:45:12 ***************************************
16/10/2024 11:45:12 *** XOpenDisplay failed (127.0.0.1:0)
*** x11vnc was unable to open the X DISPLAY: "127.0.0.1:0", it cannot
continue.
*** There may be "Xlib:" error messages above with details about the
failure.
...
Maybe a simple loop with nslookup for X-server service should be added to
the vnc container, since the order of container startup is not guaranteed
by Kubernetes, the x-server may start too early (or too late).
—
Reply to this email directly, view it on GitHub
<#353 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23N27Y6SGZ4KT76KETTZ3ZIMBAVCNFSM6AAAAABQBJNR56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWGYYDQOJQGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hello, we have tried version 2.7.2 and it is the same. @bukovjanmic has a suspicion that this might be related to startup order as mentioned in @mikevader comment - the solution is so far to wait for the service to start |
Bug description
When starting a new selenium browser over the moon-ui a new browser pod is scheduled correctly but the VNC connnection can not be established. We tested it with edge, chrome and firefox but in the following print outs I always use the output of chrome.
From our analysis it looks like X11 was started correctly but was ready after VNC was already started and therefore failed.
Analysis/Experienced Behaviour
According to the output of kubectl the
vnc-serverwas terminated. Output ofoc describe pod chrome-...:kubectl-describe-chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b.log
I attached the log of the VNC Container but as far as I could see, the log says that VNC could not be started because of the missing connection to X11:
chrome-101-0-4951-54-1-e9865711-e22c-4e1e-9d28-462416abd57b-vnc-server.log
The X-Server Container seems to work and verified it with debugging the VNC Container were I could start VNC correctly. It looks to me like a timing issue. Here is what I did:
Expected Behaviour
There should either be some flag for a startup delay or some type of retry or startup when x11 ready behaviour.
Additional Context
The text was updated successfully, but these errors were encountered: