18

How to I keep gradle from ever talking to the daemon?

./gradlew --no-daemon -Porg.gradle.daemon=false -Dorg.gradle.daemon=false build -x test
Starting daemon
IDLE

We run jenkins nodes on ecs so the daemon doesn't seem to buy us much. In addition, we run several gradle executions in a parallel jenkins pipeline block and sometimes see daemon errors - which I would not expect:

[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
Daemon vm is shutting down... The daemon has exited normally or was terminated in response to a user interrupt.

It seems that gradle needs to the daemon around to then not use it. I'm going to try giving in and using the daemon which is what gradle daemon docs recommend.

Peter Kahn
  • 12,364
  • 20
  • 77
  • 135

3 Answers3

2

Putting org.gradle.daemon=false in ~/.gradle/gradle.properties works for me.

There is a caveat, as it still needs to fork a process in order to change the JVM settings. This process is effectively the same as the regular daemon, but is private to the current build and terminates afterwards.

To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.0/userguide/gradle_daemon.html#sec:disabling_the_daemon. Daemon will be stopped at the end of the build

If the JVM settings already match then it won't do this.

Note that while you get a "less efficient" build, you do get the gradle cache pruned after every run. Otherwise it's only pruned when the shared daemon exits, which may be never in a CI system.

OrangeDog
  • 36,653
  • 12
  • 122
  • 207
0

I found this which worked for me (Gralde 6.4), based upon what OrangeDog was saying re: the jvm fork: https://github.com/gradle/gradle/issues/11517, chanseokoh's 2nd comment

Basically, I set the env var GRADLE_OPTS to match the jvm settings in my gradle.properties, and it no longer forked the JVM and thus honored the --no-daemon setting.

Example:

gradle.properties

org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=4096m -XX:+HeapDumpOnOutOfMemoryError

In shell

GRADLE_OPTS="-Xmx4096m -XX:MaxPermSize=4096m -XX:+HeapDumpOnOutOfMemoryError"
Brian Ledsworth
  • 61
  • 4
-10

Give up and accept that --no-daemon is less optimal. Running with the daemon, even on a single use jenkins ECS based node improves performance. This is especially so for situations where multiple gradle executions run on the same node at the same time via a pipeline parallel block.

If the daemon is a problem, then fixing that is better than trying to disable it.

Peter Kahn
  • 12,364
  • 20
  • 77
  • 135
  • 1
    Would you happen to have any useful tips to share from your experience? I am currently fighting these daemon deaths that are failing the pipeline. – Vas May 24 '20 at 06:49
  • @vas I recommend you ask a question with as much detail as you feel you can expose. We use the daemon in an jenkins pipleine running on ECS inside docker containers. It works pretty well for us. We also started using the buildcaching with artifactory backing it for additional compilation avoidance and speed. Stackoverflow and the gradle forums are closely monitored by the gradle team and they respond often – Peter Kahn May 26 '20 at 22:49
  • 1
    This is not helpful. – Laurent Pireyn Apr 12 '21 at 17:32
  • I couldn't figure it out. so, best of luck to you all. I had hoped someone from the gradle dev team would answer the question. There are gradle forums which may bet a better place to ask https://discuss.gradle.org/ – Peter Kahn Apr 13 '21 at 17:02