Build fails on Fedora 22 Linux

Question

Build fails on Fedora 22 Linux

seanf opened this issue 8 years ago · 9 comments

The build command mvn clean install fails dependency resolution with this message
[ERROR] Failed to execute goal on project redis-backed-cache: Could not resolve dependencies for project org.testcontainers.examples:redis-backed-cache:jar:NOVERSION: Failed to collect dependencies at org.rnorth.visible-assertions:visible-assertions:jar:1.0.2 -> org.fusesource.jansi:jansi:jar:[,1.11): No versions available for org.fusesource.jansi:jansi:jar:[,1.11) within specified range -> [Help 1]

If I apply the fix from #3 the code can be built, but the tests fail with these messages:

13:07:58.079 [main] INFO  org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying Environment variables, system properties and defaults. Resolved: 
    uri=https://localhost:2376
    sslConfig='LocalDirectorySSLConfig{dockerCertPath=/home/sflaniga/.docker}'
    version='{UNKNOWN_VERSION}'
    username='sflaniga'
    password='null'
    email='null'
    serverAddress='https://index.docker.io/v1/'
    dockerCfgPath='/home/sflaniga/.dockercfg'

13:07:58.467 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.467 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.468 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.468 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.468 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - I/O exception (org.testcontainers.shaded.org.apache.http.conn.UnsupportedSchemeException) caught when processing request: https protocol is not supported
13:07:58.468 [main] INFO  org.testcontainers.shaded.org.apache.http.impl.execchain.RetryExec - Retrying request
13:07:58.469 [main] INFO  org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying docker-machine
13:07:58.537 [main] INFO  org.testcontainers.dockerclient.DockerConfigurationStrategy - Found docker-machine, and will use machine named 
13:07:58.545 [main] INFO  org.testcontainers.dockerclient.DockerConfigurationStrategy - Looking for Docker environment. Trying local Unix socket (unix:///var/run/docker.sock)
13:07:58.588 [main] INFO  org.testcontainers.dockerclient.DockerConfigurationStrategy - Accessing docker with local Unix socket
13:08:02.419 [main] WARN  org.testcontainers.DockerClientFactory - Encountered and ignored error while checking disk space
org.testcontainers.shaded.com.github.dockerjava.api.DockerClientException: Could not pull image: null
        at org.testcontainers.shaded.com.github.dockerjava.core.command.PullImageResultCallback.awaitSuccess(PullImageResultCallback.java:49) ~[testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at org.testcontainers.DockerClientFactory.checkDiskSpace(DockerClientFactory.java:142) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at org.testcontainers.DockerClientFactory.checkDiskSpaceAndHandleExceptions(DockerClientFactory.java:125) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:89) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:70) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:101) [testcontainers--testcontainers-1.0.5-g75d09d4-2.jar:na]
        at RedisBackedCacheTest.<init>(RedisBackedCacheTest.java:18) [test-classes/:na]
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.8.0_91]
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [na:1.8.0_91]
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.8.0_91]
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423) [na:1.8.0_91]
        at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217) [junit-4.12.jar:4.12]
        at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266) [junit-4.12.jar:4.12]
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.12.jar:4.12]
        at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263) [junit-4.12.jar:4.12]
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) [junit-4.12.jar:4.12]
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) [junit-4.12.jar:4.12]
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363) [junit-4.12.jar:4.12]
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) [surefire-junit4-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) [surefire-junit4-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) [surefire-junit4-2.12.4.jar:2.12.4]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_91]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_91]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_91]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_91]
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) [surefire-api-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) [surefire-booter-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) [surefire-booter-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) [surefire-booter-2.12.4.jar:2.12.4]
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) [surefire-booter-2.12.4.jar:2.12.4]
13:08:02.508 [main] INFO  🐳 [redis:3.0.6] - Pulling docker image: redis:3.0.6. Please be patient; this may take some time but only needs to be done once.
13:08:13.691 [main] ERROR 🐳 [redis:3.0.6] - Retry limit reached while trying to pull image: redis:3.0.6. Please check output of `docker pull redis:3.0.6`

Despite the messages, I'm not out of disk space. If I try docker pull redis:3.0.6 as suggested, there is no error:

Trying to pull repository docker.io/library/redis ... 3.0.6: Pulling from library/redis

cb6fb082434e: Already exists 
d4b2ba78e3b4: Already exists 
96ee3f6ffa87: Already exists 
2feb6003bd2b: Already exists 
0ab2b63da119: Already exists 
049c59590de6: Already exists 
3c19570e002d: Already exists 
70f598fa4206: Already exists 
62c1a48300f5: Already exists 
0f997ba7600c: Already exists 
b97dabec1a3d: Already exists 
25ff6ad2020c: Already exists 
51dfd40e6465: Already exists 
30084b4aa8fb: Already exists 
e174820a222a: Already exists 
8b1a71a14171: Already exists 
ba4630529798: Already exists 
Digest: sha256:6a692a76c2081888b589e26e6ec835743119fe453d67ecf03df7de5b73d69842
Status: Image is up to date for docker.io/redis:3.0.6

Also, I have tried building with the latest release instead of "-SNAPSHOT":

mvn clean install -Dtestcontainers.group=org.testcontainers -Dtestcontainers.version=1.0.5

and the results are similar.

Answer 1 · 2016-06-10T03:56:26.000Z

Thanks - that looks really odd. I'm not quite sure what's happening yet but from those logs it looks like:

configuring the docker client from your environment variables is failing due to docker-java/docker-java#419, whereby https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling back to using docker-machine, then local unix socket, to discover your docker daemon
curiously the docker-machine name is not resolving (it's coming up blank). There's possibly a display-related or other bug here.
for some reason Testcontainers is encountering an error checking your host disk space - however this is non-fatal. This is quite likely to be related to output format from the df command, probably related to reporting of volumes.
the Could not pull image: null is a red flag that something is going wrong after this, though. It seems very odd for a string to be going missing - warrants investigation of the data flow.

It doesn't make much sense for this to be a Fedora 22-specific issue, but we'll have to see!

Richard

Answer 2 · 2016-06-10T04:01:29.000Z

I didn't realise docker-machine was installed on this box. I'm not sure why
it is installed, but I haven't set up any machines.

Perhaps it would be better to try the unix socket, and then docker-machine?

On 10 June 2016 at 13:56, Richard North notifications@github.com wrote:

Thanks - that looks really odd. I'm not quite sure what's happening yet
but from those logs it looks like:

configuring the docker client from your environment variables is
failing due to docker-java/docker-java#419
docker-java/docker-java#419, whereby https
DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is falling
back to using docker-machine, then local unix socket, to discover your
docker daemon

curiously the docker-machine name is not resolving (it's coming up
blank). There's possibly a display-related or other bug here.

for some reason Testcontainers is encountering an error checking
your host disk space - however this is non-fatal. This is quite likely to
be related to output format from the df command, probably related to
reporting of volumes.

the Could not pull image: null is a red flag that something is going
wrong after this, though. It seems very odd for a string to be going
missing - warrants investigation of the data flow.

It doesn't make much sense for this to be a Fedora 22-specific issue, but
we'll have to see!

Richard

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT
.

Answer 3 · 2016-06-10T04:08:35.000Z

I don't have any DOCKER* environment variables, https or otherwise.

Here's the output of docker-machine ls:

$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

$

As I said, no machines, so I guess that output isn't entirely strange.

The problem might be with the socket:

$ ll /var/run/docker.sock
srw-rw----. 1 root docker 0 Jun 9 16:31 /var/run/docker.sock

$

As I recall, I had some contortions getting docker commands to work without
needing sudo in front of them, so I may have changed the permissions on the
socket. Perhaps only docker can talk to the socket with those
permissions... but /usr/bin/docker is not suid, so I'm not sure how it's
working.

On 10 June 2016 at 14:00, Sean Flanigan sean@flanigan.org wrote:

I didn't realise docker-machine was installed on this box. I'm not sure
why it is installed, but I haven't set up any machines.

Perhaps it would be better to try the unix socket, and then docker-machine?

On 10 June 2016 at 13:56, Richard North notifications@github.com wrote:

Thanks - that looks really odd. I'm not quite sure what's happening yet
but from those logs it looks like:

configuring the docker client from your environment variables is
failing due to docker-java/docker-java#419
docker-java/docker-java#419, whereby
https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is
falling back to using docker-machine, then local unix socket, to discover
your docker daemon

curiously the docker-machine name is not resolving (it's coming up
blank). There's possibly a display-related or other bug here.

for some reason Testcontainers is encountering an error checking
your host disk space - however this is non-fatal. This is quite likely to
be related to output format from the df command, probably related to
reporting of volumes.

the Could not pull image: null is a red flag that something is
going wrong after this, though. It seems very odd for a string to be going
missing - warrants investigation of the data flow.

It doesn't make much sense for this to be a Fedora 22-specific issue, but
we'll have to see!

Richard

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT
.

Answer 4 · 2016-06-10T04:50:30.000Z

I forgot that I had downloaded docker-machine to /usr/local/bin/

But removing it doesn't seem to have changed the error messages except to
eliminate this line:

13:07:58.537 [main] INFO
org.testcontainers.dockerclient.DockerConfigurationStrategy - Found
docker-machine, and will use machine named

As for the socket permissions, my user is in the docker group, so the
socket should be readable and writeable.

Also, if both a docker socket and docker-machine are found, is it better to
use the socket and ignore docker-machine? And what if there is no "default"
machine yet? Perhaps it should offer to create one? (Not that I want it to
in this case, on Linux. I want to use Docker directly, even though
docker-machine may be installed.)

On 10 June 2016 at 14:08, Sean Flanigan sean@flanigan.org wrote:

I don't have any DOCKER* environment variables, https or otherwise.

Here's the output of docker-machine ls:

$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

$

As I said, no machines, so I guess that output isn't entirely strange.

The problem might be with the socket:

$ ll /var/run/docker.sock
srw-rw----. 1 root docker 0 Jun 9 16:31 /var/run/docker.sock

$

As I recall, I had some contortions getting docker commands to work
without needing sudo in front of them, so I may have changed the
permissions on the socket. Perhaps only docker can talk to the socket with
those permissions... but /usr/bin/docker is not suid, so I'm not sure how
it's working.

On 10 June 2016 at 14:00, Sean Flanigan sean@flanigan.org wrote:

I didn't realise docker-machine was installed on this box. I'm not sure
why it is installed, but I haven't set up any machines.

Perhaps it would be better to try the unix socket, and then
docker-machine?

On 10 June 2016 at 13:56, Richard North notifications@github.com wrote:

Thanks - that looks really odd. I'm not quite sure what's happening yet
but from those logs it looks like:

configuring the docker client from your environment variables is
failing due to docker-java/docker-java#419
docker-java/docker-java#419, whereby
https DOCKER_HOST URLs were not allowed. Nevertheless, Testcontainers is
falling back to using docker-machine, then local unix socket, to discover
your docker daemon

curiously the docker-machine name is not resolving (it's coming up
blank). There's possibly a display-related or other bug here.

for some reason Testcontainers is encountering an error checking
your host disk space - however this is non-fatal. This is quite likely to
be related to output format from the df command, probably related to
reporting of volumes.

the Could not pull image: null is a red flag that something is
going wrong after this, though. It seems very odd for a string to be going
missing - warrants investigation of the data flow.

It doesn't make much sense for this to be a Fedora 22-specific issue,
but we'll have to see!

Richard

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADTi_BbJinX2XHMYVDMmM15kTHdDZY-ks5qKOBqgaJpZM4IwjvT
.

Answer 5 · 2016-06-10T04:54:23.000Z

Yes, I think the docker-machine aspect is a red herring - the real problem seems to be coming when, for whatever reason, it's trying to pull a container image named null.

In the 1.1-rc1 branch the issue of over-eagerly using docker-machine is resolved; it will use environment variables, followed by unix socket, followed by docker-machine if all else fails.

Answer 6 · 2016-06-10T04:58:59.000Z

On 10 June 2016 at 14:54, Richard North notifications@github.com wrote:

Yes, I think the docker-machine aspect is a red herring - the real problem
seems to be coming when, for whatever reason, it's trying to pull a
container image named null.

Also, why does it keep trying to pull another image (not null) afterwards?

In the 1.1-rc1 branch the issue of over-eagerly using docker-machine is
resolved; it will use environment variables, followed by unix socket,
followed by docker-machine if all else fails.

Yes, that sounds right.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADTi_csZ1BK2nu0eIVsmrJLJZ7mFFbFks5qKO3_gaJpZM4IwjvT
.

Answer 7 · 2016-06-10T12:08:29.000Z

Actually re-reading the stack trace, it's not trying to pull a null image - null is the exception message, and it's a failure when pulling the image used for disk space checks. Furthermore, it's getting a second pull failure when trying to pull the redis image.

I'm not quite sure why yet, though.

Please could you let me know the versions of docker daemon you have and the version of docker-machine you [have/]had?

Answer 8 · 2016-06-10T15:47:03.000Z

On 10 June 2016 at 22:08, Richard North notifications@github.com wrote:

Actually re-reading the stack trace, it's not trying to pull a null image

null is the exception message, and it's a failure when pulling the image
used for disk space checks. Furthermore, it's getting a second pull failure
when trying to pull the redis image.

I forgot to mention - every time it said to run 'docker pull redis' (or
similar) for a better error message, I did that, but there was no error.
Not for "null" though, obviously. I could pull that one manually if you let
me know what the image name is, but I suspect it won't tell us anything,
given that fetching redis manually didn't help.

I'm not quite sure why yet, though.

Please could you let me know the versions of docker daemon you have and
the version of docker-machine you [have/]had?

From memory it's docker (daemon) 1.9 (although if I installed from Fedora
repos it must have been 1.8 according to
https://apps.fedoraproject.org/packages/docker), and docker-machine must
have been docker-machine-Linux-x86_64 v0.7.0. I'll have to check the exact
version of docker later. Probably 1.8, not 1.9.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADTi2vVKtFi5bsOInrOI2nEVM1TACIMks5qKVO-gaJpZM4IwjvT
.

Answer 9 · 2016-06-13T08:01:01.000Z

It was docker 1.8.2-7.gitcb216be.fc22 x86_64.