Error: Could not start container #955
Comments
|
Problem seems to be in this line: Can you please run this image manually with docker run and see what happens? |
@kiview Thank you for the quick response. I tried the example from the docker hub |
|
Sorry, I don't have any real clue here. Best debugging idea for me is looking into the container logs while they are starting and before the exception appears (also Docker daemon logs maybe). |
|
They are using Mint. For now I ended with using multiple GenericContainers. Thank you for help, I will try to investigate the docker daemon 🙂 |
|
I actually prefer using multiple container objects over docker-compose for
most Testcontainers use cases, so no objection here ;)
javorka <notifications@github.com> schrieb am Mi., 7. Nov. 2018, 10:39:
… They are using Mint. For now I ended with using multiple
GenericContainers. Thank you for help, I will try to investigate the docker
daemon 🙂
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#955 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE2jaEOiZ7FoopbF6C60nss3D4t8AcYFks5usqo0gaJpZM4YOtO8>
.
|
|
Hi It's seems I'm having the similar problem. Could not start alipne:socat/latest internally KafkaContainer is suing SocatContainer. My integration test uses Versions used: |
|
The problem which I posted yesterday got solved by cleaning up iptables rules, bridge network devices, and routing table entries created by docker containers. But still I noticed that the image containers are not properly stopped if there are test failures. I've an application which has around 100~ integration tests. All uses testcontainer-postgresql and about 50 tests failed due to some other reasons. And I found that at the end |
|
Having the same issue as @faris-git - any progress on this? |
|
Pruned the networks, stopped and removed all Docker containers, restarted the Docker engine as well as MacOS, upgraded |
|
@faris-git the cleanup of containers (and networks) should be tackled automatically, so something is not right here... Do you see any logs from ResourceReaper or ‘Ryuk’ during test runs? In particular, any errors from these components? Sent with GitHawk |
I ran into this issue when I run many tests in one job and if more tests got interrupted(e.g. due to ApplicationContext could not start). I see that when the tests are interrupted then testcontainer couldn't stop the container properly(especially socat container). As in error stack above |
|
While there might be scenarios in which the containers can't be shutdown properly during the test execution, they should always be removed shortly after JVM exit. So when you checked that the containers where still running, was the JVM still running as well? |
You are right the containers are stopped one by one after JVM exit. But found that the opened networks are not killed/prune properly. That's the reason in my case kafka couldn't start that there are no free socat(zookeeper) available somehow.May be it could be system based. After manually clearing the docker networks all went fine :) 'docker network prune` |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this. |
|
This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case. |
|
Encountering this issue with networks not being pruned properly leading eventually to the error. Pruning the networks does resolve it as a workaround, but could definitely use a permanent fix. Some co-workers running into this 1/day |
|
Are you sure this is the same issue? |
|
Fairly certain it's the same issue, I can prune the networks, run tests that invoke testcontainers, and the network is still showing when I run docker network ls. I'm running 1.11.1 |
|
@nateha1984 are you running Docker Compose or "normal" containers? |
|
We're using Docker Compose |
|
Just hit what I believe is the same issue - and |
|
There seems to be a bug in Docker Compose, I reported it here: |
|
It looks like the workaround suggested in the Docker Compose issue won't work with testcontainers at the moment as testcontainers is using DC 1.8.0 and v2.1 compose files are compatible with DC 1.9.0+. Any plans to upgrade the DC version? |
|
@nateha1984 can you use the local compose mode? |
Then @shin-, the maintainer from Docker Compose, said in that thread:
The solution to this issue is to use Docker Compose file version Docker Compose will either have to support tagging of networks with file version @rnorth, @bsideup: Are you guys going to support Compose file version |
|
In my case the issue went the same scenario as in the original report:
I realized that this one day was exactly the day I added some lightweight unit tests alongside with the integration tests with Testcontainers' docker-compose. I am using static singleton container pattern. plus: running Given all that (and logs), my suspicion is that the container is run twice: once in I'm going to experiment with some options. The first thing I thought of is:
Maybe this gives others some ideas on how to resolve it. UPD The issue was solved for me by introducing lazy instantiation of the compose testcontainer in tests. |
|
We have a very similar issue with a docker-compose based tests (using Testcontainers) hanging on Jenkins (ubuntu) but run fine locally (mac, windows). The same test runs successfully sometimes on the Jenkins then fails 10 times in a row (sporadic). Network seems ok - the slave is a freshly installed ubuntu slave without anything else running (physical pc, not a vm or circleCI env etc.). Pruning everything and restarting the whole machine has little effect. No obvious errors can be seen - it just hangs there and fails after waiting for at least 10minutes. Which is also strange because timeout is actually 5 minutes ... anyway - would be nice to have docker-compose stuff running correctly. Normal testcontainer tests run perfectly. For now we just convert all docker-compose based tests to multiple testcontainers. So far this is working for us. But maybe you could deprecate docker-compose tests until this is fixed in a stable manner as it is time consuming to switch testing styles. |
|
@Schwaller we do recommend using |
|
@bsideup thx for the quick response! I understand that its not ideal that DNS seems to be not perfect but this never stopped any other process from working correctly. I can run the docker-compose file on that machine manually without any issues. Just as soon as testcontainers&docker-compose is involed chances are around 80% that within a month it will develop sporadic issues. |
|
BTW thx for creating/maintaining testcontainers! Great stuff! |
|
encounter this issue too (testcontainer: 1.17.3). after disable the docker-compose v2. the issue is solved.
|
Hello everyone,
I'm using testcontainers for E2E testing our Spring application. Everything was working, but one day on my PC (my colleague don't have any problem) it started crashing.
docker-compose upis working, I cleaned the whole docker cache, volumes, images, containers..., I cleaned all the gradle build, but I'm still receiving the following error:Can anybody help me?
Thanks
The text was updated successfully, but these errors were encountered: