I’m working with Gradle 8.2.1 + JDK 17 on an ancient (14.04) Ubuntu system. (I’m not at liberty to update the system at this point.) The project builds successfully on some other systems. But on this system, gradlew stops every time after a few seconds with “build daemon disappeared unexpectedy”.
(I am running gradlew with --no-daemon which, as you know, launches a daemon process and then terminates it as soon as the build is finished. I also tried it without --no-daemon and the behavior is the same as what’s described here.)
There isn’t any indication of an error in the daemon log. I tried the --debug, --info, and --stacktrace options, but they don’t yield any more information about what happened to the daemon.
Is there any way I can supply some options or configuration in order to get some insight about why the daemon process is terminating unexpectedly? Thanks for any ideas.
as you know, launches a daemon process and then terminates it as soon as the build is finished.
… if necessary
If the CLI process would be sufficient for running the build, it would be used and really no daemon started.
Is there any way I can supply some options or configuration in order to get some insight about why the daemon process is terminating unexpectedly?
Most probably there is no additional information that can be retrieved by Gradle, as most probably the OS or something else just hard-killed the daemon process from outside and there is nothing Gradle could do against it or even recognize the cause.
Have for example a look a the OS log files.
One typical reason when this happens is, if the oom memory killer of *nix sees that the phsyical RAM is near to exhaustion and decides to kill some process at its own discretion to free memory before the whole system stalls. This for example you would find in OS log files.
Thanks for your reply. You said, “If the CLI process would be sufficient for running the build, it would be used and really no daemon started.” Is there a way to force the CLI process to execute the build without starting a separate process? I have searched extensively for information about that and I have come up empty-handed. If there is a way to do that, I would be interested to hear about it.
I looked in the various log files in /var/log, and examined the output of dmesg, but there is no record of any actions taken with respect to any Gradle process; in particular there is no record of the OOM killer being invoked.
Is there a way to force the CLI process to execute the build without starting a separate process?
As I said, if --no-daemon is used and the CLI process is suitable to run the build, it will be used, if not, a daemon process will be started and ended after the build.
The point usually making it incompatible is the max heap setting for the CLI process which is very small as the CLI usually does not need more and additionally the instrumentation agent that is usually not there on the CLI process.
But it depends on the project, that could for example also require other JVM args or system properties that are immutable and cannot be changed in the running process, making the CLI process incompatible.
But with a default build without customizations, for example running GRADLE_OPTS="-Xmx512m -javaagent:D:/Dateien/.gradle/wrapper/dists/gradle-8.2.1-bin/5hap6b9n41hkg4jeh2au2pllh/gradle-8.2.1/lib/agents/gradle-instrumentation-agent-8.2.1.jar" ./gradlew help --no-daemon does not start a new daemon process but uses the CLI process.
You can also run with --debug to see the arguments with which the daemon is started to find any others that might be necessary, or you can debug into org.gradle.launcher.cli.BuildActionsFactory#canUseCurrentProcess which is the place where the decision is made to use the CLI process or start a new single-use daemon.
Thanks for the hints. Looks like the decision to reuse the existing process or launch a new one is made in .../configuration/BuildProcess.java in the method configureForBuild. Looks like there are several factors which are taken into account. I wasn’t table to puzzle out which requirement is failing in my case but anyway, that’s the place to look.
I find that with --info, I get the log message
[INFO] [org.gradle.launcher.daemon.configuration.BuildProcess] Checking if the launcher JVM can be re-used for build. To be re-used, the launcher JVM needs to match the parameters required for the build process: --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx4096m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant
and so I tried supplying all of those options, but it doesn’t seem to make a difference; the test still fails and gradle still launches a separate process.
Supplying --debug doesn’t show any additional info about for what reason the test failed.
Right below the line you mentioned, also on --info level, you see the exact arguments that are used to start the daemon process.
From those you can try to strip down what is necessary.
In your case the necessary arguments are most likely -Xmx4096m -javaagent:<GRADLE_USER_HOME>/wrapper/dists/gradle-x.x-bin/xxxxx/gradle-x.x/lib/agents/gradle-instrumentation-agent-x.x.jar.