How do I determine why my Gradle Daemon died? The only message I get isL
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
This occurs in an active build. Several steps will finish and a step will appear to be active and then the build fails.
This began after moving our memory args (Xmx Xms PermGen) from a shell script that called gradlew to gradle.properties and calling gradlew directly.
build.sh
export GRADLE_OPTS="\"-Xmx1024m\" \"-Xms256m\" \"-XX:MaxPermSize=256m\""
export JAVA_HOME="/usr/local/java/jdk1.6"
exec ./gradlew "$#"
Addition to gradle.properties
org.gradle.java.home=/usr/local/java/jdk1.6/
org.gradle.jvmargs=-Xmx1024m -Xms256m -XX:MaxPermSize=256m
After this change Gradle warns:
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
And even though we don't ask it to, the build is running in a daemon, which ultimately fails.
Gradle build daemon disappeared unexpectedly most frequently occurs when something else kills the long-running Gradle Daemon process and the client process (the Daemon uses local TCP connections to communicate) tries to send a message and gets no response.
For example, running gradle --stop or killall java while a build is occurring will reproduce this problem.
Related
I am using jibdockerbuild to build an image to run into Docker for windows.
It's as simple as gradle jibdockerbuild using the command line.
I am making a script to build multiple images and here is how it looks like
pushd sevice0
gradle jibDockerBuild
popd
sleep 2
pushd sevice1
gradle jibDockerBuild
popd
sleep 2
pushd service2
gradle jibDockerBuild
popd
The issue with this is as follows:
Gradle randomly fails to start due to being busy even after finishing the command given.
Using the command line scenario (non-script) I just have to re-execute the command and it will work fine error message would be something like Daemon busy
The naif solution I had is to add sleep 2 which will give Gradle extra time to finish.
But if I have a slower machine, The sleep 2 will keep the issue.
Had in mind to use Gradle --stop after each gradle jibdockerbuild but it will even take more time to start Gradle Daemon again with each gradle jibdockerbuild command.
Question :
Is there a configuration I can add so Gradle won't fail to start a new daemon for each command? something like Parallel?
Is there any way I can do a fast check with my script before I run the next gradle jibdockerbuild ?
Am simply looking for a way to build all the images over any machine, without having any failure possibilities.
Additional info :
Gradle version 6.9
java 11.0.16 2022-07-19 LTS
Docker version 20.10.16, build aa7e414
I canceled a running Gradle build and now I get the following message whenever I restart it:
Could not create service of type FileHasher using BuildSessionServices.createFileHasher().
> Cannot lock file hash cache (/data/.gradle/6.4.1/fileHashes) as it has already been locked by this process.
try running (if gradle in installed on your machine and in the PATH)
gradle --stop
or
./gradlew --stop
in your project directory
from the command line. worked for me.
run
gradlew --stop
in the terminal for Windows
For Mac user run
./gradlew --stop
from root of you project
The solution is to look for the gradle process and to kill it. In my case I had to look for a running java process.
So in htop I searched for java and terminated it. That solved my problem.
We were seeing mysterious failures in our CI environment when running tests of a Kotlin code base.
gradle test compiled the code and the tests just fine. The tests ran and all appeared to pass. But then Gradle exited with code 137 (indicating it was killed with SIGKILL) and the CI system thus thought the build had failed.
Limiting the size of the JVM for Gradle didn't help. Nor did the --no-daemon and --max-workers options.
This is using Kotlin 1.2.40 and Gradle 4.3 on the Java 8 JVM.
The culprit in this case turned out to be the Kotlin compiler.
By default, the Kotlin compiler spawns a daemon in the background so that subsequent compilation jobs are faster. For a Kotlin code base of nontrivial size, this process can end up eating significant memory.
Its presence was causing Gradle to hit the memory limit on the CI container, and the Linux OOM killer was killing the Gradle process.
The solution: Tell the Kotlin compiler not to spawn the background process. This turns out to be a simple matter of setting an environment variable:
GRADLE_OPTS=-Dkotlin.compiler.execution.strategy=in-process
With that variable in place, Kotlin compilation runs inline in the Gradle JVM, and its data can thus be garbage-collected when Gradle moves on to running the tests.
It would also work to pass the option to the gradle command rather than setting it in the environment.
With gradle run -t my java application restarts nicely after exit whenever a src file changed. But can I use Gradle to terminate a running app and restart it?
I can see using -d that Gradle detects the change while my app is running.
[DEBUG] [org.gradle.internal.filewatch.jdk7.WatchServiceFileWatcherBacking] Received file system event: FileWatcherEvent{type=MODIFY, file=/usr/src/app/src/main/java/App.java}
[DEBUG] [org.gradle.internal.filewatch.jdk7.WatchServiceRegistrar] Calling onChange with event FileWatcherEvent{type=MODIFY, file=/usr/src/app/src/main/java/App.java}
But as documented restart requires that "the build task and its dependencies complete without error".
I'm running in Docker, hence the IDE's support for compile during run can't be used. For Node.js I use Nodemon for this kind of development setup.
I no longer think that this would make Java development any more efficient. See https://discuss.gradle.org/t/how-to-restart-a-run-in-continuous-mode/23221/11.
I'm trying to debug some unit tests I've written but the gradle daemon seems to always launch, ignoring any options I've set.
Using Mac OS X 10.9.5, Java 1.7, Gradle 2.2.1 and robolectric-gradle-plugin 0.14.1
Launching gradle with:
GRADLE_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5006"
./gradlew test --no-daemon -Dorg.gradle.debug=true
causes the following line to appear
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguid....
I've also tried setting the -Xdebug and Xrunjdwp as jvmArgs in build.gradle.
Nothing else happens but if I add -d and rerun, it turns out that the daemon has launched and is waiting on port 5005 for a debugger: http://pastebin.com/TqaXubmr
Finally, if I then launch a debugger attaching to port 5005 the tests run but none of the breakpoints are hit.
The gradle.properties is empty, I haven't set org.gradle.jvmargs.
You might have configure memory settings in your gradle.properties? these can force gradle to launch a new jvm as these settings cannot be applied dynamically.
Keep in mind that unit tests are always executed in a separate jvm. The easiest way to debug tests executed by gradle is to run
>gradle :test --debug-jvm
this will automatically configure your test task to run with debug enabled.