Gradle-daemon is started too often

Old Forum Archive Bugs
1

First of all I would like to note that I’m running gradle from within a docker container. GRADLE_USER_HOME points to a directory which is located on the Windows part. (this location is linked to the docker container when starting it with the -v option.

When using gradle, I very often notice the message
’’‘Starting a Gradle Daemon, 3 incompatible and 2 stopped Daemons could not be reused, use --status for details’’’

Consequently the build is slower as necessary.

Looking at gradle --status:
’’‘root@devenv:/home/tarand# gradle --status
PID STATUS INFO
790 IDLE 3.1
778 STOPPED (by user or operating system)
35892 STOPPED (by user or operating system)
36462 STOPPED (by user or operating system)’’’

Sometimes I even see more than one daemin in IDLE state.

What can be the reason?

Gradle 3.1

Build time: 2016-09-19 10:53:53 UTC
Revision: 13f38ba699afd86d7cdc4ed8fd7dd3960c0b1f97

Groovy: 2.4.7
Ant: Apache Ant™ version 1.9.6 compiled on June 29 2015
JVM: 1.8.0_101 (Oracle Corporation 25.101-b13)
OS: Linux 4.4.20-moby amd64

Is this a regression? If yes, which version of Gradle do you know it last worked for?

2

Hi Thomas,

Based on your “3 incompatible” Daemons output, I’d say that some part of our development environment is causing Daemons to be incompatible.

To be compatible, a Gradle invocation must have the same JAVA_HOME, Gradle version, and relatively same JVM args (for example, memory bounds and SSL keystore config must be identical).

If you run your build with --info, Gradle will log a more precise reason why it had to start a new Daemon. Using Gradle build scans will also tell you Daemon longevity and amount of reuse, which may help you trace the cause of this.

If you would like to provide more information from at least one of these sources, I’m happy to help you understand why you’re seeing too many new Daemons.

Cheers,
Eric

3

Hi Eric,
thanks for your answer.
I guess it has something to do with running eclipse (with gradle nature) on windows (NOT within that docker container). However, in order to only have one download cache for gradle, I configured the GRADLE_USER_HOME en-variable in order to point to the same directory in both cases.
I just started some builds in my docker container. It re-uses the same daemon.
Then I switched to eclipse and did a gradle->Refresh Gradle Project command. After that, I switched back to docker and re-issued the gradle command again. This time it restarted the daemon!
Here is the output:

######################################################################
root@devenv:…/my-aktion-2nd/my-aktion-ws# gradle compileJava --info
Initialized native services in: /home/tarand/gradle/native
Found daemon DaemonInfo{pid=2277, address=[1203c81f-6428-4822-94d2-d764a2f11040 port:41813, addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Idle, lastBusy=1475757750567, context=DefaultDaemonContext[uid=7ed1f5b0-26e1-4c71-a008-7b5f819bccfc,javaHome=\usr\lib\jvm\java-8-oracle,daemonRegistryDir=\home\tarand\gradle\daemon,pid=2277,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]} however its context does not match the desired criteria.
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/usr/lib/jvm/java-8-oracle,daemonRegistryDir=/home/tarand/gradle/daemon,pid=4899,idleTimeout=null,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=7ed1f5b0-26e1-4c71-a008-7b5f819bccfc,javaHome=\usr\lib\jvm\java-8-oracle,daemonRegistryDir=\home\tarand\gradle\daemon,pid=2277,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]

Looking for a different daemon…
Found daemon DaemonInfo{pid=13776, address=[ab4d1792-d2e7-40a8-b451-ffddc9887fbe port:51776, addresses:[/127.0.0.1, /0:0:0:0:0:0:0:1]], state=Idle, lastBusy=1475824141980, context=DefaultDaemonContext[uid=47e75dd0-2839-4012-9678-ec6a33f2c46a,javaHome=C:\Program Files\Java\jdk1.8.0_101,daemonRegistryDir=C:\Users\tarand\Documents\dev\gradle\daemon,pid=13776,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=windows-1252,-Duser.country=DE,-Duser.language=de,-Duser.variant]} however its context does not match the desired criteria.
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/usr/lib/jvm/java-8-oracle,daemonRegistryDir=/home/tarand/gradle/daemon,pid=4899,idleTimeout=null,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=47e75dd0-2839-4012-9678-ec6a33f2c46a,javaHome=C:\Program Files\Java\jdk1.8.0_101,daemonRegistryDir=C:\Users\tarand\Documents\dev\gradle\daemon,pid=13776,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=windows-1252,-Duser.country=DE,-Duser.language=de,-Duser.variant]

Looking for a different daemon…
Found daemon DaemonInfo{pid=4630, address=[55d18b71-d964-4651-86a3-593f7c1134af port:45209, addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Idle, lastBusy=1475761175913, context=DefaultDaemonContext[uid=722d8fab-bea5-499b-8d48-da74a39aea98,javaHome=\usr\lib\jvm\java-8-oracle,daemonRegistryDir=\home\tarand\gradle\daemon,pid=4630,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]} however its context does not match the desired criteria.
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/usr/lib/jvm/java-8-oracle,daemonRegistryDir=/home/tarand/gradle/daemon,pid=4899,idleTimeout=null,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=722d8fab-bea5-499b-8d48-da74a39aea98,javaHome=\usr\lib\jvm\java-8-oracle,daemonRegistryDir=\home\tarand\gradle\daemon,pid=4630,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]

Looking for a different daemon…
Removing 0 daemon stop events from registry
Starting a Gradle Daemon, 3 incompatible Daemons could not be reused, use --status for details
####################################################################

Thanks,
Thomas

4

Two different machines cannot share the same Gradle user home. The Gradle user home contains the daemon registry which will get corrupted if different machines write to it. This then causes daemons to be stopped and restarted as you are seeing.

What happens in your specific case is that the Java home path is converted to Windows file notation, so it no longer matches the original Unix path.

But even if this wasn’t the case, there would be a more fundamental problem: When you launch Gradle on your host, it will read the daemon registry and find the entries created by your docker container. If the configuration matched up (let’s say your host also used Unix), it would try to connect to the daemon and fail since it doesn’t actually run on the host. It would then remove that daemon from the registry for being unresponsive. The daemon sees that it was removed from the registry and kills itself.

You can share the caches/modules-2 sub-directory to avoid re-downloading dependencies, but the rest of the user home should be separated.

5

I assumed such a situation. However, I do not mind having the daemon registries separated on the two environments. The question is: As this location is controlled via GRADLE_USER_HOME, and both “daemon” and “caches” are subdirectories of GRADLE_USER_HOME: how can I achieve that “daemon” is different in both environments, but “caches” is identical?

6

You would only link the caches dir of your host into the container instead of linking the full user home.

7

Yes, that seems to work! Thanks!
(However, it would be easier if gradle would provide an env-variable for selection of the daemon’s “home” dir.)