Hello Experts, Disable Daemon Q. How do we disable daemon with JDK 21 ❓ With JDK 8, matching GRADLE_OPTS with org.gradle.jvmargs and extra

-Dorg.gradle.daemon=false

did the trick. But, same is not working with JDK21

gradle --no-daemon clean build

flag also launches daemon Why I want to disable daemon? On my build machine, gradle build completes, but does not exits. It hangs there for some reason unknown. For this, with JDK 8, we had disabled daemon and it worked. Same is now happening for JDK21.

Gradle 8.6

That is not Java 8 vs. Java 21, but old Gradle vs. newer Gradle. Nowadays

--no-daemon

almost always means "use a one-off daemon and shut it down after executing the build". That

--no-daemon

really does not start a daemon you have to make sure the CLI process is suitable for the build process, i.e is compatible with the necessary daemon args. Most prominently these are JVM args and the instrumentation agent that Gradle uses to instrument the build classpath for example to detect configuration cache inputs and iirc for some other things. If you run with

--info

maybe, if not then when running with

--debug

, you see the arguments with which the daemon is started and there you could extract what is necessary.

You have any suggestion on how we can debug hang issue? jstack and debug logs would be good starting point. Anything else?

Maybe use the

gradle-profiler

to run through a profiling tool that can tell you where the time is spent?

I will try to get the profiler logs and full jstack output . But here is a excerpt which I suspect is the problem.

"Stdin handler" #33 [1211019] prio=5 os_prio=0 cpu=1101.53ms elapsed=31499.58s tid=0x00007f2408011640 nid=1211019 in Object.wait()  [0x00007f2455f4e000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait0(java.base@21.0.4/Native Method)
        - waiting on <no object reference available>
        at java.lang.Object.wait(java.base@21.0.4/Object.java:366)
        at java.io.PipedInputStream.awaitSpace(java.base@21.0.4/PipedInputStream.java:279)
        at java.io.PipedInputStream.receive(java.base@21.0.4/PipedInputStream.java:237)
        - locked <0x00000000d0ebbbb8> (a java.io.PipedInputStream)
        at java.io.PipedOutputStream.write(java.base@21.0.4/PipedOutputStream.java:154)
        at java.io.OutputStream.write(java.base@21.0.4/OutputStream.java:124)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$1.onInput(ForwardClientInput.java:54)
        at org.gradle.launcher.daemon.server.DefaultDaemonConnection$StdinQueue.doHandleCommand(DefaultDaemonConnection.java:299)
        at org.gradle.launcher.daemon.server.DefaultDaemonConnection$StdinQueue.doHandleCommand(DefaultDaemonConnection.java:286)
        at org.gradle.launcher.daemon.server.DefaultDaemonConnection$CommandQueue$1.run(DefaultDaemonConnection.java:259)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.4/ThreadPoolExecutor.java:1144)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.4/ThreadPoolExecutor.java:642)
        at java.lang.Thread.runWith(java.base@21.0.4/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.4/Thread.java:1583)

No idea, but I'd guess that is not a problem, but just a thread waiting for input from the CLI 🤷‍♂️

Profiler, yes I saw. On the

--continuous

I have to check, but not setting/passing it explicitly in my builds

The user (or build) controls which daemon args are necessary (except for the instrumentation agent), and if the CLI process does not fulfill the requirements, it does not really make sense to try using it imho. Running a build with a setup you know will fail as the build's requirements are not fulfilled would be a very bad use experience. Especially as the CLI process by default has very minimal memory settings that will almost always result in out of memory. I also doubt that running directly in the CLI will fix a hanging build, actually. Regarding better display which parameters are necessary for true daemon-less, there is a feature request ticket iirc. But especially with the instrumentation agent this is anyway not too trivial and changes each time you change the Gradle version. And running without instrumentation agent (it can be disabled, but shouldn't) is also not really a good idea, as it does important work for reliable and correct builds and will lead to subtle problems that a user could probably not easily see the cause for it even notice. Having said all that, feel free to open a feature request with your suggestion to see what the Gradle folks think about it, I'm just a user like you, sharing my experience and expertise.

Daemon Hang State

I have no idea. If you really think that is the cause, you should probably open a bug report with all information you have, so it could eventually be fixed if there really is some bug. Did you check whether continuous more is used or not? You could for example really check in a build

--scan

if that is possible. If not, I think it might work too print out the value of https://docs.gradle.org/current/javadoc/org/gradle/StartParameter.html#isContinuous() to verify.

Thanks for your suggestions. I am interested in knowing the reason for hanging, so I will try a ticket route.