[quarkus-container-image-jib] No progress after "Container entrypoint set to" with quarkus 3.17.6 (3.15.2 works)

[clahres]

Describe the bug

When running the quickstart "getting-startet-reactive" with quarkus-container-image-jib plugin, the build stops progress at

[INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Container entrypoint set to [/opt/jboss/container/java/run/run-java.sh]

Expected behavior

Build finishes

Actual behavior

Build does not finish

How to Reproduce?

• checkout getting-startet-reactive
• add dependency quarkus-container-image-jib
• add property <quarkus.container-image.build>true</quarkus.container-image.build>
• run .\mvnw clean install

Output of uname -a or ver

OS: Windows 10 Pro; Version: 22H2; OS build: 19045.5247

Output of java -version

openjdk-23.0.1

Quarkus version or git rev

3.17.6

Build tool (ie. output of mvnw --version or gradlew --version)

maven-3.9.9

Additional information

When I use quarkus 3.15.2, the build finishes successfully.
Maybe this is related? GoogleContainerTools/jib#4267

[quarkus-bot]

/cc @geoand (jib)

[geoand]

I could not reproduce this problem

[clahres]

Ok, I'll take a look into it. I thought this may be a windows problem.

[HerrDerb]

I experience the same with out project that is using gradle. Likely the same issue🤷‍♂️I think I also can confirm that it only occurred on windows, on unix/mac it runs through.
Right after

2025-01-14T09:20:21.965+0100 [INFO] [io.quarkus.container.image.jib.deployment.JibProcessor] Container entrypoint set to [./application, -Djava.net.preferIPv4Stack=true,  -XX:+ExitOnOutOfMemoryError, -XX:MaxDirectMemorySize=80m]

gradle seems to be blocked/waiting with no further logs of the build process

2025-01-14T09:22:02.698+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2025-01-14T09:22:02.699+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2025-01-14T09:22:02.699+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2025-01-14T09:22:02.700+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2025-01-14T09:22:02.700+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2025-01-14T09:22:02.701+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2025-01-14T09:22:12.694+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2025-01-14T09:22:12.694+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2025-01-14T09:22:12.694+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2025-01-14T09:22:12.695+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2025-01-14T09:22:12.695+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2025-01-14T09:22:12.695+0100 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
...

[geoand]

Does the same thing happens with a Windows + Maven setup?

[HerrDerb]

@geoand I think @clahres described it with Windows + Maven. But as the issue he also attached, it looks like jib itself struggled with a "Deadlock on windows on build" lately, so it might not be an issue of quarkus. https://github.com/GoogleContainerTools/jib/releases

Bug might have been introduced with: GoogleContainerTools/jib#4249

[geoand]

Has anyone taken it up with the Jib team?

[HerrDerb]

There is a rather basic reopen: GoogleContainerTools/jib#4339
I might fill it in a bit more and mention that it has gotten an issue when using quarkus

[geoand]

🙏🏽