Docker-images: Hung when building 18.4.0

Created on 5 Mar 2020  路  13Comments  路  Source: oracle/docker-images

OS: macOS Catalina 10.15.3
CMD: ./buildDockerImage.sh -v 18.4.0 -x

I am trying to build the 18.4.0-XE version and am getting hung in two places:

...
Complete!
Loaded plugins: ovl <-- Hung here for 2 minutes
Examining ...

and

...
Successfully built 272b967feafc
Successfully tagged oracle/database:18.4.0-xe <-- Hung here indefinitely 

For the last one I need to go into system management and end the yes process. So this is likely due to this line:
https://github.com/oracle/docker-images/blob/f472904a92cec25c2cf508ed7d1f5d1d81a12487/OracleDatabase/SingleInstance/dockerfiles/buildDockerImage.sh#L225-L226

bug database

Most helpful comment

I'd like to reopen this issue as I am facing the same problem.

I was looking in my Activity Monitor what was eating my CPU during and saw that the process 'yes' was taking almost all my CPU for one of the cores. After killing this process building the Docker was almost instantly done.

The yes command is used in the prune step to approve pruning as can be seen by the original message.

Doing a quick google found me this on the yes command: https://lifehacker.com/stress-test-your-mac-with-the-yes-command-1564681908. It can apparently be used to 'stress test' your mac...

Hence, I think the yes command has a nasty side effect when run on a mac..

All 13 comments

The first hang is not a hang, it's yum not displaying any output during the build process. It's furiously updating things in the background, just not logging anything.

The second hang is also likely not a hang, just taking a very long time to prune dangling images on your system. You can run that command manually first, i.e. docker image prune before you build so you can see the output.

Okay the first part makes sense. If this is the step that downloads the database install binary then I would expect a 2 minute wait time.

However, I disagree with the second hand. Even if I had multi-gigabit amount of images to clean up in the prune command, this command should not take > 10 minutes. This only happens when doing an 18.4.0 build.

You're right, it shouldn't, but I can understand that it does. The step cleans up all the dangling layers and on a Mac, Docker uses a hidden VM which has fairly woeful filesytem performance. I would expect the time taken to create and remove those layers could be a while, especially given how large some of those layers for 18.4 can be.

Having said that, even if it is a hang, it's one caused by Docker, not this Dockerfile/script. I would again suggest commenting out that line from the buildDockerImage.sh script (which is provided for convenience, but not actually required) and run just docker image prune to see how long it takes.

docker image prune outside of this script takes my system sub-second time to complete. I'll go ahead and leave this issue open just in case anyone else faces this issue. Perhaps it is a docker on mac issue?

I'm going to close this issue because it's outside the scope of this repository.

I'd like to reopen this issue as I am facing the same problem.

I was looking in my Activity Monitor what was eating my CPU during and saw that the process 'yes' was taking almost all my CPU for one of the cores. After killing this process building the Docker was almost instantly done.

The yes command is used in the prune step to approve pruning as can be seen by the original message.

Doing a quick google found me this on the yes command: https://lifehacker.com/stress-test-your-mac-with-the-yes-command-1564681908. It can apparently be used to 'stress test' your mac...

Hence, I think the yes command has a nasty side effect when run on a mac..

@gvenzl perhaps this line should be removed from the buildDockerImage.sh script? I can't see any value in it now. Users should maintain and manage their own layers (including dangling ones) and Docker provides plenty of commands to do that these days.

Yeah, that seems like a better solution.

Is this repo open to community PRs? If so I would be more than willing to create a PR for this.

Is this repo open to community PRs? If so I would be more than willing to create a PR for this.

Absolutely. Please review the Contribution Guide (CONTRIBUTING.md) in the root which outlines the requirements for signing the Oracle Contributor Agreement prior to submitting a PR, but we'll gladly accept them.

Okay, looks like oracles contributor agreement takes quite a lot of liberties with intellectual property. Unfortunately, I won't be able to make a contribution at this time. 馃槶

Okay, looks like oracles contributor agreement takes quite a lot of liberties with intellectual property. Unfortunately, I won't be able to make a contribution at this time. 馃槶

That's a shame. Note that the Oracle Contributor Agreement FAQ outlines why we need the contributor agreement and how it protects both Oracle and contributing developers. We use the same type of agreement used by other large organisations including the Apache Foundation and Free Software Foundation.

Was this page helpful?
0 / 5 - 0 ratings