video-recorder: "Cannot open display 127.0.0.1:0, error 1." #437
Comments
|
Make sure that you are using correct image of x-server comtainer, should be
quay.io/aerokube/xvfb-server:2.6.2.
чт, 13 февр. 2025 г., 11:25 toby181 ***@***.***>:
… Hi together,
We got a moon setup in version 2.6.2 running on k8s.
From around 50 test cases which all should create and upload a video to s3
around 70% of them were failing with the following exception:
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.2.1 (Alpine 11.2.1_git20220219) 20220219
configuration: --prefix=/usr --pkg-config-flags=--static --extra-libs='-lpthread -lm -lz' --extra-ldexeflags=-static --enable-gpl --enable-static --enable-small --enable-avfilter --enable-libx264 --enable-libxcb --disable-ffplay --disable-ffprobe --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-w32threads --disable-alsa --disable-audiotoolbox --disable-cuda --disable-cuvid --disable-d3d11va --disable-dxva2 --disable-nvenc --disable-vaapi --disable-vdpau --disable-videotoolbox --disable-librtmp --disable-devices --disable-debug --disable-asm --enable-indev=xcbgrab
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat 58. 76.100 / 58. 76.100
libavdevice 58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc 55. 9.100 / 55. 9.100
[x11grab @ 0x7fc98f135030] Cannot open display 127.0.0.1:0, error 1.127.0.0.1:0: I/O error
stream closed EOF for moon/chrome-129-0-6fc68560-e725-4092-b1cd-dc6f056c36e4 (video-recorder)
The video-recorder container stops with status 'completed', it does not
crash (from a pod POV).
It's not the test case itself nor resources, we verified that.
My assumption is that the video-recorder container is starting too early
while the others are not yet up and therefore can't connect.
The workaround that we got in place is to use
quay.io/aerokube/video-recorder:latest. This way k8s will always pull the
image, due to latest tag, and the container starts last since it needs to
pull the image first, which the other containers do not need to do since
we're using an image proxy to cache them or they're already available on
the node.
Due to an upload bug in the video-recorder image in version 2.7.2 it makes
no sense to update since we have to use the latest tag there anyway.
—
Reply to this email directly, view it on GitHub
<#437>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23LI2KUIGU5SQ4DSJWD2PRJH7AVCNFSM6AAAAABXBRVVLGVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA2TAMZRGQ3DIOI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Those are the images that we use |
|
Video recorder also should be 2.6.2 for 2.6.2 moon release.
чт, 13 февр. 2025 г., 11:59 toby181 ***@***.***>:
… Those are the images that we use
quay.io/aerokube/ca-certs:2.6.2
quay.io/browser/google-chrome-stable:129.0
quay.io/aerokube/defender:2.6.2
quay.io/aerokube/xvfb-server:2.6.2
quay.io/aerokube/vnc-server:2.6.2
quay.io/aerokube/video-recorder:latest
—
Reply to this email directly, view it on GitHub
<#437 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23NQ4N26PQOKLHPHKG32PRNHHAVCNFSM6AAAAABXBRVVLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJVHEZTOMBUGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
The issue occurs with version 2.6.2 of the video-recorder but is tackled (workaround) with 'latest' tag. I see, what was not clearly stated in my initial report, sorry. |
|
Latest tag is only compatible with 2.7.2, please note that latest image is
not always pulled, it is pulled only if some of layers changed. We will
release 2.7.3 in few days.
чт, 13 февр. 2025 г., 13:10 toby181 ***@***.***>:
… The issue occurs with version 2.6.2 of the video-recorder but is tackled
(workaround) with 'latest' tag
—
Reply to this email directly, view it on GitHub
<#437 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23J3FGK3HL6NDXZ6YBT2PRVPVAVCNFSM6AAAAABXBRVVLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWGEYDOOJRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ok, let me explain again and separate the topics. 2.6.2 + video-recorder:latest
2.6.2 + video-recorder:2.6.2We got moon in version 2.6.2 deployed and our browser pods are running with those images: From around 50 test cases which all should create and upload a video to s3 around 70% of them were failing with the following exception: The video-recorder container stops with status 'completed', it does not crash (from a pod POV). |
|
Ok, please see if there are OOM kills.
чт, 13 февр. 2025 г., 15:39 toby181 ***@***.***>:
… Ok, let me explain again and separate the topics.
2.6.2 + video-recorder:latest
- Latest tag is compatible with version 2.6.2 since we're using that
successfully. The video is uploaded to s3. Every pod succeeds.
quay.io/aerokube/ca-certs:2.6.2quay.io/browser/google-chrome-stable:129.0quay.io/aerokube/defender:2.6.2quay.io/aerokube/xvfb-server:2.6.2quay.io/aerokube/vnc-server:2.6.2quay.io/aerokube/video-recorder:latest
- Latest tag is, in case of moon browser pods, always pulled, see the
official kubernetes documentation: Default image pull policy
<https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting>:
"if you omit the imagePullPolicy field, and the tag for the container image
is :latest, imagePullPolicy is automatically set to Always;"
If you check the browser pod there is no imagePullPolicy configured,
therefore it's using the default values.
2.6.2 + video-recorder:2.6.2
We got moon in version 2.6.2 deployed and our browser pods are running
with those images:
quay.io/aerokube/ca-certs:2.6.2quay.io/browser/google-chrome-stable:129.0quay.io/aerokube/defender:2.6.2quay.io/aerokube/xvfb-server:2.6.2quay.io/aerokube/vnc-server:2.6.2quay.io/aerokube/video-recorder:2.6.2
From around 50 test cases which all should create and upload a video to s3
around 70% of them were failing with the following exception:
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 11.2.1 (Alpine 11.2.1_git20220219) 20220219
configuration: --prefix=/usr --pkg-config-flags=--static --extra-libs='-lpthread -lm -lz' --extra-ldexeflags=-static --enable-gpl --enable-static --enable-small --enable-avfilter --enable-libx264 --enable-libxcb --disable-ffplay --disable-ffprobe --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-w32threads --disable-alsa --disable-audiotoolbox --disable-cuda --disable-cuvid --disable-d3d11va --disable-dxva2 --disable-nvenc --disable-vaapi --disable-vdpau --disable-videotoolbox --disable-librtmp --disable-devices --disable-debug --disable-asm --enable-indev=xcbgrab
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat 58. 76.100 / 58. 76.100
libavdevice 58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc 55. 9.100 / 55. 9.100
[x11grab @ 0x7f6e01000030] Cannot open display 127.0.0.1:0, error 1.127.0.0.1:0: I/O error
stream closed EOF for moon-namespace/chrome-129-0-473cf699-bbcd-4b2b-abf1-e2beaf6ce7d8 (video-recorder)
The video-recorder container stops with status 'completed', it does not
crash (from a pod POV).
—
Reply to this email directly, view it on GitHub
<#437 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23MWTCDRSWDTAXQWM232PSHANAVCNFSM6AAAAABXBRVVLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWGQ3TQOBUGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
No OOM. The video-recorder container stops immediately but with the reason 'Completed', not Error or OOM. All of the other containers are proceeding. |
|
2.7.3 released, please check it.
чт, 13 февр. 2025 г., 16:22 toby181 ***@***.***>:
… No OOM. The video-recorder container stops immediately but with the reason
'Completed', not Error or OOM. All of the other containers are proceeding.
video-recorder:
Container ID: containerd://4a105994e84a1bf7665b1cdb24c835a1db98bcea7411546ef333057f0e42a291
Image: quay.io/aerokube/video-recorder:2.6.2
Image ID: ***@***.***:29b09bfb3874eb4f8d0a00e423dd41b9bf4f871a0f04919e326e6dc55db7dce4
Port: <none>
Host Port: <none>
State: Terminated
Reason: Completed
Exit Code: 0
Started: Thu, 13 Feb 2025 14:20:06 +0100
Finished: Thu, 13 Feb 2025 14:20:06 +0100
Ready: False
Restart Count: 0
Limits:
cpu: 4
memory: 8Gi
Requests:
cpu: 1
memory: 1000Mi
—
Reply to this email directly, view it on GitHub
<#437 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKY23MHSBH4CJFFIZKC3ZT2PSMBRAVCNFSM6AAAAABXBRVVLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWGU4DQNZTGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Version 2.7.3 looks quite good. We ran a lot of tests and no issues so far, all video-recorder container started properly. Thanks for providing that version so quickly and fixing the issue. Much appreciated! Those are the images that we were using, all are the default ones from helm. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi together,
We got a moon setup in version 2.6.2 running on k8s.
From around 50 test cases which all should create and upload a video to s3 around 70% of them were failing with the following exception:
The video-recorder container stops with status 'completed', it does not crash (from a pod POV).
It's not the test case itself nor resources, we verified that.
My assumption is that the video-recorder container is starting too early while the others are not yet up and therefore can't connect.
The workaround that we got in place is to use
quay.io/aerokube/video-recorder:latest. This way k8s will always pull the image, due to latest tag, and the container starts last since it needs to pull the image first, which the other containers do not need to do since we're using an image proxy to cache them or they're already available on the node.Due to an upload bug in the video-recorder image in version 2.7.2 it makes no sense to update since we have to use the latest tag there anyway.
The text was updated successfully, but these errors were encountered: