Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) while building Android project on Jenkins

Question

I have an Android Project that builds successfully on Android Studio.

Now I want to build it on Jenkins. But when I'm doing I got the following error: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Exception is:

org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
    at org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:222)
    at org.gradle.launcher.daemon.client.DaemonClient.monitorBuild(DaemonClient.java:198)
    at org.gradle.launcher.daemon.client.DaemonClient.executeBuild(DaemonClient.java:162)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:125)
    at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:80)
    at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43)
    at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:241)
    at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:214)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
    at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:207)
    at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
    at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
    at org.gradle.launcher.Main.doAction(Main.java:33)
    at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55)
    at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36)
    at org.gradle.launcher.GradleMain.main(GradleMain.java:23)

I read related topics, but it does not help. I tried to build it using gradle daemon, and without it, but the problem still exists.

i already answer it go to this link [this is from another post](https://stackoverflow.com/a/44693275/5832732) — reza rahmad, Jun 22 '17 at 07:56
I tried removing lock files under `.gradle` directory at both home and project directories, then I tried additionally removing the `~/.gradle/caches`, quitting as many processes as possible to make room and setting the `-Xmx` for the daemon to `4GB`, making sure no other Java process exists, but none of these helped. I even tried blowing away both the `.gradle` directories in both home and project directories. It is hard to believe but it started working again after restarting the OS. — haridsv, Nov 12 '21 at 07:30
Regarding my above comment, I had been building with gradle in this project for over 2 years and this is the first time this happened, so maybe it is something to do with Mac than gradle. For reference, I was using macOS `10.15.7` and `adoptopenjdk-14.jdk` installed using Brew. — haridsv, Nov 12 '21 at 07:31
It is a combination of number of parellel demons are running and how much heapspace you are utlising. - so check how much jeap is avaliable and create a configuration accordingly #-Xms256m -Xmx1024m - Number of forks = number of parallel test cases are exectuing ``` tasks.test { maxParallelForks=2 } ``` so ideally you can expect minimum 2 parallel demon is running with max = 2* 1024 memory. if you have more demon running and you keep on increase heap space. that also cause out of memory — Arjun Nagathankandy, Mar 31 '23 at 15:16
Happens a lot in WSL when other processes take away memory, despite giving enough memory with JVM args — Marian Klühspies, Apr 29 '23 at 08:56

score 46 · Answer 1 · edited Jun 20 '20 at 09:12

46

EDIT Looks like there has been a few changes with the new versions of Gradle.

Since 3.0 you should not disable the daemon on your CI anymore

[We] recommend using [the daemon] for both developers' machines and Continuous Integration servers.

However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.

PREVIOUS ANSWER

It's recommended to turn off daemon on any CI server. use this option to disable it

--no-daemon

edited Jun 20 '20 at 09:12

Community

1
1

answered May 11 '16 at 18:53

Oleg Khalidov

5,108
1
28
29

2

I tried to build without daemon, but then I had a memory error. When I'm trying to increase a memory limit, I got a Daemon error again. Is it possible that server where jenkins is running has a low memory? – Sandro Gedevanishvili May 11 '16 at 20:04
48

And I built with `--no-daemon` and it's still giving `Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)`. Most peculiar. – Peter K. Oct 13 '16 at 11:28
4

I'm getting the same thing, added --no-daemon, and then checking the build logs, it explicitly says 'starting up daemon' nonsense. Anyone know how to really kill it? – Dan Devine Oct 24 '16 at 23:15
@SandroGedevanishvili I'm facing exactly the same as you, how did you solve the issue? – Pedro Teran Mar 29 '17 at 15:53
2

There was a problem with Memory on the machine I was building the project. After increasing memory to the machine, problem was solved. – Sandro Gedevanishvili Apr 02 '17 at 20:55
3

This is a misquote or outdated ```Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is completely isolated from any previous builds.``` – Boris Treukhov Jan 25 '18 at 16:47

MungoRae · Answer 2 · 2017-07-26T09:24:00.963

After getting this crash I tried several things to get the GradleDaemon to stop running on my CI server. None of which worked.

I found an answer on a gradle.org forum which suggested that the GradleDaemon would always run anyway. The --no-daemon flag would just make it run for this specific build rather than staying on indefinitely.

If you specify JVM arguments that require forking, Gradle will fork a new JVM. Regardless of whether or not you want a daemon process, the class that runs is called GradleDaemon. The --no-daemon switch should cause the forked process to be single use instead of a long running daemon process, but it's still going to run the GradleDaemon class.

Source: https://discuss.gradle.org/t/no-daemon-switch-ineffective-if-jvm-settings-cause-new-fork/14919/5

I may be reading this wrong and I can't vouch for the validity of the answer, but I think the cause of this error is just a lack of memory for Gradle. As it is always going to run the GradleDaemon.

So I added

org.gradle.jvmargs=-Xmx1024m

to my ~/.gradle/gradle.properties file and it no longer gave me that error.

Tried increasing the memory, but still receiving this error! — Amal lal T L, Jan 19 '22 at 06:20

score 22 · Answer 3 · edited Oct 13 '17 at 22:51

22

It seems like it is a memory related issue. Nevertheless, disabling the daemon as suggested by Oleg does seem to help.

Use

org.gradle.daemon=false

in

gradle.properties

either in ~/.gradle folder or the project's folder.

Ref: https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:disabling_the_daemon

edited Oct 13 '17 at 22:51

jpoppe

2,228
24
25

answered Mar 17 '17 at 10:17

muthusuba

464
5
4

I was having trouble launching sonarqube from my jenkins pipeline. With this option I managed to solve the problem. – Hugo L.M May 01 '18 at 17:57
Worked for my setup running gradle in a docker container from Jenkins – Christoph May 08 '18 at 12:54

score 16 · Answer 4 · answered Oct 10 '17 at 17:54

16

In our case the issue was caused by the CI server passing environment variables with non-ascii characters (i.e. in the names of commit authors).

Adding file.encoding=utf-8 to Gradle properties fixed the issue immediately.

answered Oct 10 '17 at 17:54

akru

171
1
3

1

This was exactly also my case but setting file.encoding=utf-8 doesn't help. I had to remove special characters directly on GitLab in my account settings. – Jozef Jun 10 '19 at 17:12
I tried all above options but this one is working for me. Thanks – Pooja Sep 04 '19 at 11:35
Here I have the "amazing" idea to use emojis on the prompt. With emojis, the gradle crashes. If you want to try by yourself, on Linux you can use ```export PS1=' \w '```. The error happens on Gradle 4.10.3, but was already fixed on Gradle 6.5 (the newest today). – Topera Jun 10 '20 at 11:51
Tried that, but no luck. Disabling the gradle daemon does the trick! – hicnar Sep 15 '21 at 14:58

score 13 · Answer 5 · edited Jun 30 '22 at 06:09

It appears this type of problem (Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)) is becoming more common as people move to GitHub workflows and GitHub Actions.

We never saw this problem when building locally (command line or Android Studio), or when building on our Jenkins build server. But as soon as we started testing builds through GitHub Workflows/Actions this type of build error would happen intermittently.

Every project is different, so it appears there are several solutions that may work. After a lot of experimenting with our builds, the only parameter that reliably fixed this problem was '-XX:MaxMetaspaceSize'.

GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

No changes to build.gradle, gradle.properties, gradle-wrapper.properties, etc. were needed in our case. Just the single GRADLE_OPTS line in our GitHub workflow yaml. This explanation from the Java docs was the most helpful (avoiding unbounded growth of class metadata space).

In previous releases of Java Hotspot VM, the class metadata was allocated in the so-called permanent generation. Starting with JDK 8, the permanent generation was removed and the class metadata is allocated in native memory. The amount of native memory that can be used for class metadata is by default unlimited. Use the option -XX:MaxMetaspaceSize to put an upper limit on the amount of native memory used for class metadata.

Source: https://docs.oracle.com/en/java/javase/17/gctuning/other-considerations.html

Working example of GitHub Workflow:

jobs:
  build:

    runs-on: ubuntu-latest

    env:
      GRADLE_OPTS: -Dorg.gradle.jvmargs="-XX:MaxMetaspaceSize=1g"

    steps:
    - uses: actions/checkout@v2
      with:
        ref: 'master'
        fetch-depth: 0

    - name: Set up JDK 11
      uses: actions/setup-java@v2
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: gradle

    - name: Gradle Build
      uses: gradle/gradle-build-action@v2
      with:
        arguments: build -x lint appDistributionUploadRelease

this solution doesn't work. now I get error: GC overhead limit exceeded. (java 8) — naXa stands with Ukraine, Jun 28 '22 at 12:34
@naXastandswithUkraine the only thing this solution does is to configure your build to use a limited amount of memory for class metadata (1G in my example). This differs from the default of using unlimited memory for class metadata, which can easily cause an OOM condition and kill your build in non-obvious ways. Your problem appears to be something different (though you might try lowering the -XX:MaxMetaspaceSize parameter and see if that helps). — Tom, Jun 29 '22 at 18:08
yes, sorry. my problem was caused by something else: too high `-Xmx -Xms` values — naXa stands with Ukraine, Jun 30 '22 at 06:10
This resolved the trouble we were seeing. Using Git Hub Actions as mentioned. Thank you :) — Hodglem, Mar 07 '23 at 18:34

score 8 · Answer 6 · edited Jan 03 '18 at 06:14

8

gradle -Dorg.gradle.jvmargs=-Xmx1536m assembleDebug

Or add org.gradle.jvmargs=-Xmx1536m to gradle.properties file.

edited Jan 03 '18 at 06:14

Rahul Sharma

2,867
2
27
40

answered Jan 03 '18 at 05:28

HellenGo

81
1
1

This solved the issue for me. The difference is that I've put more memory. To be specific, I'v used the "Sample, efficient gradle.properties" from this article: https://medium.com/@wasyl/make-your-gradle-builds-fast-again-ea323ce6a435 – Milan Aug 09 '21 at 10:21

Hubbitus · Answer 7 · 2019-03-25T11:21:50.250

Gradle build daemon disappeared unexpectedly in many cases mean gradle itself or even java crashed. In my case it was java. Fill bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1408857

Look at files named like: hs_err_pid%p.log where %p is PID of process in directory from what you are run gradle task.

Update: It looks like gradle itself issue. In my case because of use native jansi. In issue provided workaround:

ln -sb /dev/null /home/pasha/.gradle/native/jansi/1.17.1/linux64/libjansi.so

score 4 · Answer 8 · answered Nov 30 '18 at 21:43

4

No one else may run into this, as it's quite silly, but...

My issue was a strange character being present in my commit message...I had copied a previous commit message from gitlab which contained an emoji and pasted that into the title of a merge request, instead of the normal :bug: syntax.

akru's answer helped point me in the right direction

answered Nov 30 '18 at 21:43

jacoballenwood

2,787
2
24
39

1

I have unicode characters in environment variables. The last message I see in the daemon log is: `03:41:36.788 [DEBUG] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Configuring env variables: {PATH=/` and then it vanishes. Unfortunately for me, adding `file.encoding=utf-8` to `~/.gradle/gradle.properties` did not solve the issue – thiago Jan 13 '19 at 03:42

score 3 · Answer 9 · answered Aug 25 '19 at 08:35

3

Wow, in my case closing the Android Studio and re-opening it worked just fine and the error was gone. :)

answered Aug 25 '19 at 08:35

Rahee

195
1
5

score 3 · Answer 10 · answered Oct 08 '21 at 05:36

In my case, removing org.gradle.parallel=true did the trick.

My gradle.properties for your reference:

org.gradle.daemon=false
org.gradle.jvmargs=-Xmx3g -XX:MaxMetaspaceSize=768m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
kotlin.compiler.execution.strategy=in-process

PS: I'm using this configuration for running Android Workflows with GitHub Actions (ubuntu-20.04)

score 1 · Answer 11 · answered Feb 09 '17 at 14:23

I have tried the --no-daemon solution but my build continued to fail with the same DaemonDisappearedException.

I solved this by increasing the RAM of the server I am running Jenkins upon. In AWS EC2 that meant having to increase the EC2 instance type which results to an increase RAM.

score 1 · Answer 12 · answered Jun 19 '18 at 21:06

1

Sometimes just doing Build -> Clean Project works - Give that a try before you start with the other gradle file changes.

answered Jun 19 '18 at 21:06

shellym

546
1
5
11

score 1 · Answer 13 · answered Jul 16 '20 at 09:58

1

Most of the time you only need to restart Android Studio and it should work. Also you can do the following: File -> Sync Project with Gradle Files and then File -> Invalides Cachse / Restart.

answered Jul 16 '20 at 09:58

Rawand Saeed

795
10
13

score 0 · Answer 14 · answered Aug 31 '17 at 13:44

0

I was using Android Studio in Windows 7 and then this error appeared. What worked for me is killing Java.exe from Windows TaskManager.

answered Aug 31 '17 at 13:44

SrikanthS

74
1
6

score 0 · Answer 15 · answered Jan 02 '19 at 23:23

In my case, I was upgrading my android studio project and I use ZelixKlassMaster for obfuscating my code the issue wa that, I had my class-path on Zelix set to 27 but my project was using android 28 Hope this will help any future comers the way I debugged this was my seed file was printing out this error

ERROR: Invalid classpath in "classpath" statement at line 69 : "C:\Users\Rab\AppData\Local\Android\Sdk\platforms\android-27\android.jar" is not a valid path.

score 0 · Answer 16 · answered Jun 03 '20 at 14:53

I had the same issue, in the end there was a missing argument in the gradle file

Basically, this was a kotlin project, in which some experimental coroutine features were used. The class which used it was marked with

@OptIn(FlowPreview::class)

This requires adding the following argument in the build.gradle, although it was running just fine in android studio locally

kotlinOptions {
        jvmTarget = "1.8"
        freeCompilerArgs = [ "-Xopt-in=kotlin.RequiresOptIn"]
    }

Spent a lot of time looking for this one

score 0 · Answer 17 · edited Aug 07 '20 at 14:02

0

Before assemble task.

./gradlew --status

check daemon status.

Then

./gradlew --stop

to stop the daemon.

Use

./gradlew assemblerelease  --no-daemon -Dkotlin.compiler.execution.strategy="in-process"

to disable daemon.

edited Aug 07 '20 at 14:02

Greenonline

1,330
8
23
31

answered Aug 07 '20 at 02:43

TerrenceZhang

1

score 0 · Answer 18 · edited Aug 12 '20 at 11:06

0

Add in gradle.properties file.

org.gradle.daemon=true <br>
org.gradle.jvmargs=-Xmx1024m <br>
android.useDeprecatedNdk=true <br>
android.useAndroidX=true <br>
android.enableJetifier=true <br>
file.encoding=utf-8

edited Aug 12 '20 at 11:06

Greenonline

1,330
8
23
31

answered Aug 12 '20 at 06:16

user2991182

1
1

score 0 · Answer 19 · answered Oct 25 '20 at 07:54

0

i had the same issue added these in the gradle.properties file

android.useAndroidX=true
android.enableJetifier=true
org.gradle.jvmargs = -Xmx2g

answered Oct 25 '20 at 07:54

Bakhtawer Jabeen

1

score 0 · Answer 20 · answered Sep 27 '21 at 14:40

I was experiencing the same issue in GitHub Actions. As other answers mention, it seemed to be a memory issue.

The following settings worked nicely for me with the GitHub Ubuntu runner (no need to disable the deamon):

# ...
env:
  GRADLE_OPTS: -Dkotlin.incremental=false -Dorg.gradle.jvmargs="-Xmx4g -XX:MaxMetaspaceSize=2g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # ...
      - name: Build app
        run: ./gradlew assembleRelease --stacktrace

score 0 · Answer 21 · answered Oct 22 '21 at 01:48

0

In my case, I was using Docker for running the Gradle tasks from Github actions locally.

I had to increase docker memory, and it worked!

answered Oct 22 '21 at 01:48

david

2,135
4
24
34

score 0 · Answer 22 · answered Nov 01 '21 at 07:17

0

I got the same error in Docker, and I tried to set org.gradle.daemon=false and all the above ways, but it didn't work . At last, I update the gradle to version 6.5 and the android gradle plugin to version 4.1.0. then the error disappeared.

answered Nov 01 '21 at 07:17

Dan You

1

score 0 · Answer 23 · answered Jan 12 '22 at 11:43

This is how it worked for me:

Enable the gradle deamon (this is the default with gradle 7).

org.gradle.daemon=false

Install Jenkins Plugin: https://plugins.jenkins.io/gradle-daemon/

The Plugin will prevent to kill the deamon if another build is still using it.

score 0 · Answer 24 · answered Mar 31 '23 at 15:18

It is a combination of number of parellel demons are running and how much heap space you are utlising. so check how much heap is avaliable and create a configuration accordingly

-Xms256m -Xmx1024m

Number of forks = number of parallel test cases are exectuing

tasks.test { maxParallelForks=2 }

so ideally you can expect minimum 2 parallel demon is running with

max = 2* 1024 memory.

NOTE: if you have more demon running and you keep on increase heap space. that also cause out of memory

So try to find an optimal count for Fork (number of parallel demons)
and heap space for it

score -1 · Answer 25 · answered May 19 '21 at 17:35

-1

I had the same problem and after a long fight, I deleted some files and got some free space in memory. then restarted android studio, now it works perfectly.

answered May 19 '21 at 17:35

Muhammad Shehzad

1

score -5 · Answer 26 · answered Jan 27 '20 at 14:29

-5

Go to /gradle.properties then remove org.gradle.jvmargs=-Xmx1024m and if org.gradle.jvmargs=-Xmx1024m not available then Add this code in your /gradle.properties.

answered Jan 27 '20 at 14:29

Arjun Yadav

27
3

11

This answer is really unclear... remove it... then add it back? – Pure Function May 13 '20 at 22:45

Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) while building Android project on Jenkins

26 Answers26

Linked