Repository navigation
Stop waiting for port when container exited #2225
Description
try (GenericContainer<?> genericContainer = new GenericContainer<>("alpine:3.7")) {
genericContainer
.withCommand("false") // exit quickly
.withExposedPorts(1234)
.waitingFor(Wait.forListeningPort().withStartupTimeout(Duration.ofSeconds(1000)))
.start(); // should fail quickly
}
Observed
Waiting for exposed port takes 1000s
Expected
Stop waiting for port, since container is exited.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a8eb2b690815 alpine:3.7 "false" About a minute ago Exited (1) About a minute ago gifted_northcutt
e9ce5b30960c quay.io/testcontainers/ryuk:0.2.3 "/app" About a minute ago Up About a minute 0.0.0.0:33383->8080/tcp testcontainers-ryuk-7cf21936-f4ce-49ac-9ab8-6d278dcb07c0
Activity
findepi commentedon Jan 4, 2020
This, combined with #2223, makes it harder to debug problems with containers non-starting:
bsideup commentedon Jan 4, 2020
Testcontainers will print the logs if container fails to start.
#1837 also improved it and will report if container failed to start.
Which version are you running?
findepi commentedon Jan 4, 2020
It does, but only after it stops waiting. So, if my container is slow to start, i need to configure large timeout.
Then, test is idling for the container to start, while it's already known to be failed.
1.12.4
stale commentedon Apr 4, 2020
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.
stale commentedon Apr 18, 2020
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.
rnorth commentedon Apr 18, 2020
I think we should double check this rather than letting it expire. It sounds like #1837 would be a partial solution but not complete. I'll reopen for further investigation.
sci-jvm-study commentedon Jul 12, 2026
I checked the current 'HostPortWaitStrategy' on 'main' and this seems to be fixed. Commit 2d57f61 (PR #6384, "Improve startup wait checks", March 2023) added a 'failFast' check in the polling loop:
.failFast("container is no longer running", () -> !waitStrategyTarget.isRunning())
This causes the wait to fail immediately if the container stops running, rather than waiting for the full startup timeout. Looks like this can
be closed.