Open micheletest opened 5 years ago
Also want to note that the host's /tmp averages about 16g and /dev/shm about 40g so there should be plenty of space on the host.
Same here. We first noticed it on May 15.
@micheletest sorry for the late reply.
Would it be possible to see the logs Zalenium and the pod where the browser was running?
Hi @diemol. See the attached gist - I've included all the pod logs that seemed relevant plus an excerpt from the zalenium log where it gets the session. I do have trouble correlating what's going on in the zalenium log with what's happening in kubernetes, so hopefully I grabbed the correct information. (if there is a common session id or something, please let me know). Also, I can grab more info if this isn't enough.
https://gist.github.com/micheletest/64d3665fd20f0d504e025d8f28630272
Is there any news? If the problem is not solved I will have to give up the Zalenium!
@micheletest The key of the issue lies here: https://gist.github.com/micheletest/64d3665fd20f0d504e025d8f28630272#file-xmanager-stderr-log
Somehow elgalu/selenium
cannot find a free display to start XVFB, could you please dig into the VM where this is running and see if there are some displays locked? It is always quite tricky when it comes to that, because I've seen some VMs where this happens often and other ones where this almost never happens. Most of the time, things work well in Ubuntu as the host OS, perhaps try Ubuntu and let us know if it gets better.
@berezovskij would be sad if you need to give up on Zalenium, I invite you to have a different perspective and help us find a way to fix the issue instead of pointing out that it has not been solved. As many other open source projects, we have limited time and resources to tackle any existing issues, we rely a lot in the community to help us getting Zalenium to a better state.
@diemol this is still happening to me. I'm still using zalenium headless, which mostly works, but I'd love to turn on video again.
Can you explain how elgalu/selenium
interacts with the host X server i.e., does this mean that this docker container connects to the host's X server? In our case, we run this Docker image on a Kubernetes cluster with Debian nodes on AWS EC2.
@elgalu can you please help with @micheletest's question?
Hi, no, it doesn't interact with the host X server, we use xvfb-run
ALL please consider to start sponsoring we do this in our free time;)
We met the same page crash issue ,how to increase the selenium container shm_size?
If some versions of Chrome work and others don't, it all points out to be a Chrome/ChromeDriver issue, right?
π Bug Report
selenium.common.exceptions.WebDriverException: Message: chrome not reachable
andselenium.common.exceptions.WebDriverException: Message: unknown error: Chrome failed to start: exited abnormally
For about a week now I've been having chrome crashes in my kubernetes setup. I have been unable to get to the cause, and it happens to different tests each time so it's hard to reproduce. But it's also consistent, this will happen every single time I run a build in ci.
The chrome driver log indicates that X server went away for chrome not reachable errors. For the Chrome failed to start error, it seems to be this issue: https://github.com/zalando/zalenium/issues/861
I have tried
--disable-dev-shm-usage
to no effect. I've tried--no-sandbox
and--disable-setuid-sandbox
which didn't help. I tried to make a customelgalu/docker-selenium
to increase theSHM_SIZE
but that didn't work because it needs to be privileged. The only thing that worked was to set my tests to headless. However this means I am getting no videos, so I consider this a temporary solution.All the research I've done seems to indicate this is related to /dev/shm. I see this is mounted automatically, but is it run in privileged mode? If not can it be set to privileged for kubernetes? Or is there a way to increase the SHM_SIZE on the selenium nodes?
To Reproduce
I am using a kubernetes setup with
image: dosel/zalenium:3.141.59k
andelgalu/selenium:3.14.0-p22
. I am using these requests/limits:Expected behavior
Chrome doesn't crash.
Test script reproducing this issue (when applicable)
none yet
Environment