Gradle --no-daemon starts the daemon?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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"