-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Codeship builds fail: can not connect to Ryuk
#581
Comments
I'm having the same issue with CircleCI. Using v1.6.0 |
Hi @estebangarcia, would it be possible for you to migrate to CircleCI 2.0? Since pre 2.0 CircleCI was using lxc directly themselves (AFAIK?), you have to jump through a lot more hoops to get Testcontainers working there. |
Hi @gavinmh, |
I'm having the same issue with version 1.8.1 |
Yes, please. Re-open this issue since it still persists in 1.8.1 |
@kiview Could you please reopen this? ty |
Reopened as requested, bug seems to be still present. |
We're experiencing the same when the load on the build server (Jenkins) is (very) high. One thing that eased the pain was upgrading docker where we used to use an early version of 2017. The docker service wasn't responsive during peak testing (eight parallel test runs) which lead me to that direction. Still, we had to reduce the number of parallel builds because of testcontainer timeouts. I haven't tried to increase |
@bountin I don't think the timeout is related to the issue we are having. I turned on the testcontainers logging and this is what I got:
As you can see, only 1.7 seconds passed between connecting to docker and the socket exception. |
After having a closer look at the code, I came up with the following findings/questions:
Sorry if the answers to some of my questions are obvious. I'm new to the project and only guessing how things should play together here. |
Now I had a build with numerous stack traces instead of just two. But after some attempts to connect it seems to get stuck in the while-loop waiting for the acknowledgment and after the 30 second timeout the |
I've created a pull request that should fix the issue. See #843. |
We're also occasionally experiencing the same issue with Spring Session builds on Jenkins. Here's the stacktrace from one of those builds:
|
Thanks for the ping - I forgot to follow up on this. We were still experiencing the problem with I'll try to remove |
I'm having the same issue with
I can't figure out how to set Here's the full debug log when running Maven with
|
@guss See the docs on custom properties. As a side note for @kiview and @bsideup, it would be nice to have |
Sorry about the weird link, Github is sometimes too enthusiastic about referencing issues. I've tried with setting the timeout to 120, and indeed the build takes 2 more minutes but the Ryuk connection still fails:
|
@guss77 Did you manage to solve this? Running into the same issue now with |
I am seeing the same issue with 1.10.6 but only on Mac running Docker Desktop Similar stack trace:
I am running this side-by-side with a Linux laptop (Docker engine 18.06.0-dev build e68fc7a) that has less memory than the Mac, but I am not seeing the issue there. |
@ysb33r Did you already try to increase the timeout in |
Yes I have set it to 120, but possibly a complete restart of Docker Desktop seemed to have resolved the problem. |
have tried creating the docker group? it solves permission issues # create new group
sudo groupadd docker
# add current user to the group
sudo usermod -aG docker $USER
# log in to the group
newgrp - docker |
Hello, any update here ? https://stackoverflow.com/questions/76442027/cannot-connect-to-ryuk |
TestContainers works locally. Builds on Codeship fail with the following:
I do not use volume mapping for this service, but I use volumes to build other services. My understanding of https://www.testcontainers.org/usage/inside_docker.html is that I do not need to mount the Docker socket volume.
I've set
add_docker: true
in mycodeship-services.yml
, which does the following:https://documentation.codeship.com/pro/builds-and-configuration/services/
The text was updated successfully, but these errors were encountered: