-
-
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
Docker for Mac HostPortWaitStrategy issue #271
Milestone
Comments
Ah, you're on Docker for Mac v1.13.0. @bsideup is this the same issue you
were seeing earlier today?
…On Fri, 20 Jan 2017 at 20:30, Mateusz Kołodziejczyk < ***@***.***> wrote:
Hey,
HostPortWaitStrategy seems to not work as expected at OS X. Container
startup fails.
Exception encountered when invoking run on a nested suite - Container startup failed
org.testcontainers.containers.ContainerLaunchException: Container startup failed
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:176)
at org.testcontainers.containers.GenericContainer.starting(GenericContainer.java:516)
at org.testcontainers.containers.TestContainerAccessor$.starting(TestContainerAccessor.scala:13)
at com.dimafeng.testcontainers.TestContainerProxy$class.starting(TestContainer.scala:110)
at com.dimafeng.testcontainers.SingleContainer.starting(TestContainer.scala:115)
at com.dimafeng.testcontainers.ForAllTestContainer$class.run(TestContainer.scala:59)
...
Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit with exception
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:83)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:169)
... 22 more
Caused by: org.testcontainers.containers.ContainerLaunchException: Could not create/start container
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:242)
at org.testcontainers.containers.GenericContainer.lambda$start$0(GenericContainer.java:171)
at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:76)
... 23 more
Caused by: org.testcontainers.containers.ContainerLaunchException: Timed out waiting for container port to open (localhost:32813 should be listening)
at org.testcontainers.containers.wait.HostPortWaitStrategy.waitUntilReady(HostPortWaitStrategy.java:90)
at org.testcontainers.containers.GenericContainer$AbstractWaitStrategy.waitUntilReady(GenericContainer.java:881)
at org.testcontainers.containers.GenericContainer.waitUntilContainerStarted(GenericContainer.java:443)
at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:221)
... 25 more
I've tried to debug this issue and what I found is that,
NullPointerException is catched by code below:
(IMO there should be a debug-level log, because at the moment nothing
suggests that it was exceptional case)
checkStrategy = () -> {
for (String[] command : commands) {
try {
if (container.execInContainer(command).getStdout().contains(SUCCESS_MARKER)) {
return true;
}
} catch (InterruptedException e) {
throw new RuntimeException(e);
} catch (Exception e) {
continue;
}
}
return false;
};
The NPE is caused by code from TestEnvironment class:
public static boolean dockerExecutionDriverSupportsExec() {
String executionDriver = DockerClientFactory.instance().getActiveExecutionDriver();
return !executionDriver.startsWith("lxc");
}
executionDriver is null. If I'm not wrong, active execution driver comes
from ExecutionDriver attribute from docker API /Info response. According
to moby/moby#24461 <moby/moby#24461>,
this attribute is no longer present in the response.
My docker info:
$ docker info
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 187
Server Version: 1.13.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 380
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.4-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952 GiB
Name: moby
ID: OOJ2:ZNKR:C4WH:UNUE:F6EI:XCP4:CIQJ:36OY:63X4:BI35:5CFI:SXQK
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 29
Goroutines: 36
System Time: 2017-01-20T20:23:49.009805267Z
EventsListeners: 1
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
And docker version:
$ docker version
Client:
Version: 1.13.0
API version: 1.25
Go version: go1.7.3
Git commit: 49bf474
Built: Wed Jan 18 16:20:26 2017
OS/Arch: darwin/amd64
Server:
Version: 1.13.0
API version: 1.25 (minimum version 1.12)
Go version: go1.7.3
Git commit: 49bf474
Built: Wed Jan 18 16:20:26 2017
OS/Arch: linux/amd64
Experimental: true
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#271>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIET1c_34K-fRgGZvbevxUJdZ5lCijLks5rURlsgaJpZM4Lpt0A>
.
|
Yes, I know that you officially support Docker for Mac v1.12, but I thought that you'd like to know that v1.13 has this issue. |
Yes, thank you - we do need to resolve it so filing a ticket was the right
thing. It's interesting that executionDriver is no longer present, so
thanks for spotting that. This could also break our exec support as well as
the port wait strategy, so we'll have to come up with an alternative
approach!
Thanks
Richard
|
#272 @coutoPL you can try it with: repo:
Dependency:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey,
HostPortWaitStrategy seems to not work as expected at OS X. Container startup fails.
I've tried to debug this issue and what I found is that, NullPointerException is catched by code below:
(IMO there should be a debug-level log, because at the moment nothing suggests that it was exceptional case)
The NPE is caused by code from TestEnvironment class:
executionDriver
is null. If I'm not wrong, active execution driver comes fromExecutionDriver
attribute from docker API /Info response. According to moby/moby#24461, this attribute is no longer present in the response.My docker info:
And docker version:
The text was updated successfully, but these errors were encountered: