VNC Container failed to startup because of missing X11 connection (timing issue)

[mikevader]

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

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:

$ 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

[aandryashin]

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: ***@***.***>

[vania-pooh]

@mikevader i.e. aerokube/xvfb-server:<your-moon-release>.

[mikevader]

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.

[mikevader]

I created a workaround which confirmed my suspicion about the timing issue:

I wrapped your VNC image with the following container:

FROM quay.io/aerokube/vnc-server:2.3.7
USER root

ADD wait-for-it.sh /opt
RUN chmod +x /opt/wait-for-it.sh

USER 4096

CMD ["x11vnc", "-xrandr", "-passwd", "selenoid", "-noxrecord", "-forever", "-display", ":0", "-shared", "-rfbport", "5900"]

ENTRYPOINT ["/opt/wait-for-it.sh", "localhost:6000", "-t", "10", "--", "/usr/sbin/init"]

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.

[vania-pooh]

@mikevader ok, one more possible solution is trying to use a bit older image: aerokube/xvfb-server:2.3.5.