[Bug]: Container fails to start after upgrade from 1.18.1 to 1.18.2 #7082
Comments
|
Have you set |
|
Nope, didn't touch that file: |
|
But following this clue you gave: if I do modify and manually add |
|
Do you have What if you delete the |
|
I have latest docker desktop as in the original report (Docker Desktop 4.20.0; Engine 24.0.2). If I delete the file, I either immediately get the same error as reported originally, and sometimes such error after 1 min: Note: using 1.18.1 works no problem with or without the file. In logs with 1.18.1 I still see localhost, but tests complete successfully: |
|
Thanks! weird! I just deleted my and if I disable which is expected 😕 |
|
Also tried While test is running I am able to "catch" ryuk container for a split-second: Is there a way to trace anything further? or replicate what testcontainers doing in command line, which I could try? Overall your guess about host seems relevant (when I explicitly set tc.host=127.0.0.1, it helps). |
|
I am wondering about |
|
Interesting. tcHost variable is Optional.empty, so it's coming from somewhere else, will keep you posted if I notice something else. |
|
Got to this point: And the method effectively returns Update: |
|
Trace logs if it helps with anything. It sounds like |
|
I do have the same issue: |
|
I am running Docker Desktop version 4.19.0 (106363) and testcontainers 1.18.2. I enabled |
|
Can you please share |
|
Thanks @gtrefs. I'm not sure how to reproduce this, for me is working as expected :/ See #7082 (comment) |
|
|
oh... I had colima installed before and it seems like it was still set to Edit: I removed the |
|
Now, I'm able to reproduce and see the reason. Thank you so much for reporting this issue! |
* Improve DockerDesktopClientProviderStrategy description * Fix TestcontainersHostPropertyClientProviderStrategy only when tc.host is present Fixes #7082
|
Cool stuff seeing this regression being tackled so quickly! We are seeing a similar error from 1.18.1 -> 1.18.2, with Kafka containers and on a linux host, as a rootless docker host. From what I am seeing this seems to be addressed just the same with the commits. (if not, let me know what I could possible provide to verify)
|
|
Testcontainers for Java 1.18.3 is out https://repo1.maven.org/maven2/org/testcontainers/testcontainers/1.18.3/testcontainers-1.18.3.pom Thank you so much for testing it so quickly and raising the issue again! |
|
I am still getting the same error, upgrading to 1.18.3 did not fix this issue. I am using ~/.testcontainers.properties Caused by: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image testcontainers/ryuk:0.5.1 |
|
I am getting the same error on mac m1/colima docker |
|
Getting error on 1.18.3 on linux. The image is actually being pulled though as it shows up in |
|
I had a similar issue and adding the following line to the ~/.testcontainers.properties |
|
I just had to troubleshoot the same issue with a colleague who has an M1 Mac and testcontainers
@eddumelendez would you mind reopening the issue as it doesn't seem to be fixed at the moment? |
|
Can you please upgrade to 1.18.3? |
|
It was happening on 1.18.3 |
|
@monosoul |
|
@eddumelendez yeah, what I meant is that downgrading to |
|
Okay, this is weird. The colleague has now removed |
|
I had the same issue on my M1 Mac and resolved it from these instructions here: https://vividcode.io/colima-apple-m-1-and-testcontainers/ I set the following environment variables: DOCKER_HOST="unix://$HOME/.colima/default/docker.sock" |
|
I had a similar problem and solved it by just cleaning my docker install: |
I can confirm that this works for me on Mac M2, Podman. But now I'm wondering, why does testcontainers need |
Problem solved in Intel Mac and Ventura. |
|
Same issue on Mac M1 arm64 and testcontainers 1.19.1, adding privileged=true to properties didn't help |
|
testcontainers dependency 1.19.6 and docker image testcontainers/ryuk:0.3.1 specified in |
|
I got the same on cat ~/.testcontainers.properties
#Modified by Testcontainers
#Thu Mar 07 15:22:17 CET 2024
docker.client.strategy=org.testcontainers.dockerclient.UnixSocketClientProviderStrategy
testcontainers.reuse.enable=falseThe error is: latest macOS, arm64 (M1) |
|
Getting same error for testcontainers/sshd:1.1.0 tectcontainers version 1.19.5, MacOs M1 Pro, Sonoma 14.3.1 ` Caused by: |
|
@ALL, thank you all for the feedback. my ~/.testcontainers.properties file is now #Sun Jun 16 17:42:57 WAT 2024 running on Mac M2 docker, when i deleted the ~/.testcontainers.properties it was recreated. my current stack trace is 2024-06-16 17:42:57,458 INFO [org.tes.ima.PullPolicy] (build-38) Image pull policy will be performed by: DefaultPullPolicy() 2024-06-16 17:43:00,524 INFO [io.qua.dep.dev.IsolatedDevModeMain] (main) Attempting to start live reload endpoint to recover from previous Quarkus startup failure Caused by: io.quarkus.builder.BuildException: Build failure: Build failed due to errors Caused by: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/vectorized/redpanda:v22.3.4 Please can anyone help? I appreciate |
|
I fixed this issue modifying the ~/.zshrc file with this configuration |
Module
PostgreSQL
Testcontainers version
1.18.2
Using the latest Testcontainers version?
Yes
Host OS
MacOS Ventura 13.4
Host Arch
ARM (Apple M2)
Docker version
Client: Cloud integration: v1.0.33 Version: 24.0.2 API version: 1.43 Go version: go1.20.4 Git commit: cb74dfc Built: Thu May 25 21:51:16 2023 OS/Arch: darwin/arm64 Context: desktop-linux Server: Docker Desktop 4.20.0 (109717) Engine: Version: 24.0.2 API version: 1.43 (minimum version 1.12) Go version: go1.20.4 Git commit: 659604f Built: Thu May 25 21:50:59 2023 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.6.21 GitCommit: 3dce8eb055cbb6872793272b4f20ed16117344f8 runc: Version: 1.1.7 GitCommit: v1.1.7-0-g860f061 docker-init: Version: 0.19.0 GitCommit: de40ad0What happened?
After upgrading org.testcontainers:postgresql dependency from 1.18.1 to 1.18.2 tests fail to run.
Failure happens in .start method:
Relevant log output
Additional Information
No response
The text was updated successfully, but these errors were encountered: