The daemon will not start

Old Forum
1

I thought this was working for me in the recent many weeks, but it’s not working now: the daemon does not start, nor can I get my build to use it unless I explicitly specify --daemon on the command line.

Here is some console output:

$ cat gradle.properties
org.gradle.daemon=true

$ gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
  com.example.qa.reflection.MainTest > testReflection STANDARD_OUT
    one:two
:check
:build
  BUILD SUCCESSFUL
  Total time: 4.351 secs

$ jps -l
62588 sun.tools.jps.Jps

$ gradle -v
  ------------------------------------------------------------
Gradle 1.3
------------------------------------------------------------
  Gradle build time: Tuesday, November 20, 2012 11:37:38 AM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.6.0_37 (Apple Inc. 20.12-b01-434)
OS: Mac OS X 10.7.5 x86_64

When I set --debug on the command line, I see on daemon related logging except for

13:17:09.918 [DEBUG] [org.gradle.initialization.ProjectPropertySettingBuildLoader] Adding project properties (if not overwritten by user properties): [org.gradle.daemon]

I re-read the User Guide, and cannot discern what I am doing wrong.

Anybody?

Thank you.

2

A bit more info:

If I start the build with --daemon, I see output in the associated daemon log file under $HOME/.gradle/daemon/

If I invoke gradle again without --daemon, I see no output in the daemon log and the build takes about 4x as long.

3

That’s the expected behavior as ‘–daemon’ only affects the current build.

Can you double-check that your ‘gradle.properties’ is in the root project directory, and that it doesn’t contain any funky characters? I’ve never heard of this problem before. Also try with ‘export GRADLE_OPTS=-Dorg.gradle.daemon=true’.

4

Here is confirmation that gradle.properties is in my root project directory:

$ ls -al
total 56
drwxr-xr-x
12 petrovic
CORP\Domain Users
 408 Dec
6 14:12 .
drwxr-xr-x
21 petrovic
CORP\Domain Users
 714 Dec
6 10:49 ..
drwxr-xr-x
 4 petrovic
CORP\Domain Users
 136 Dec
6 13:12 .gradle
drwxr-xr-x
14 petrovic
CORP\Domain Users
 476 Dec
6 14:02 .idea
drwxr-xr-x
 8 petrovic
CORP\Domain Users
 272 Dec
6 13:57 build
-rw-r--r--@
1 petrovic
CORP\Domain Users
 323 Dec
6 11:32 build.gradle
drwxr-xr-x
 3 petrovic
CORP\Domain Users
 102 Dec
6 13:55 gradle
-rw-r--r--
 1 petrovic
CORP\Domain Users
  23 Dec
6 14:12 gradle.properties
-rwxr-xr-x
 1 petrovic
CORP\Domain Users
5080 Dec
6 13:55 gradlew
-rw-r--r--
 1 petrovic
CORP\Domain Users
2404 Dec
6 13:55 gradlew.bat
-rw-r--r--
 1 petrovic
CORP\Domain Users
 978 Dec
6 13:58 reflection-lab.iml
drwxr-xr-x
 4 petrovic
CORP\Domain Users
 136 Dec
6 10:49 src

Here are two different representations of my gradle.properties file showing no special characters (I checked the hex output character by character):

$ hexdump -C gradle.properties
 00000000
6f 72 67 2e 67 72 61 64
6c 65 2e 64 61 65 6d 6f
|org.gradle.daemo|
00000010
6e 3d 74 72 75 65 0a
                            |n=true.|
00000017
  $ hexdump -c gradle.properties
 0000000
 o
 r
 g
 .
 g
 r
 a
 d
 l
 e
 .
 d
 a
 e
 m
 o
0000010
 n
 =
 t
 r
 u
 e
\n
                                    0000017

Running with export GRADLE_OPTS=-Dorg.gradle.daemon=true results in the daemon being used.

But I think I have a dim idea of what is going on. I hope this is not a red herring, so hold on tight…

The project directory I am working in is one I consider a standalone project - it’s a one-off spike project. It has no parent, as in multiproject. But three levels directly up there exists an unrelated build.gradle and settings.gradle file (that does not refer to the project that is the subject of this thread). However, one level directly up from this thread’s project there exist no gradle related files. This configuration of directories does not end up using a running daemon.

Next: move this thread’s project to a directory that contains no parent that contains any file related to gradle. Now when I build, the daemon is used.

I have some dtruss output on the Mac that shows a lot more gradle files being found higher in the path for the first case vs. the second (a condition which I explicitly arranged for, given what I said in the preceding two paragraphs). I don’t show that here, but I can post it later if it matters. (sudo dtruss -f x.sh # where x.sh contains “gradle build”).

It appears to me that gradle in the first case is walking up the file system and finding files that are not logically related to this thread’s build, and somehow using the file content or the existence of those files to influence this thread’s build.

That file is settings.gradle three levels up, which does not reference this thread’s project. That file contains an ‘include’ statement that references other subprojects. (Eventually I will clean this up and not have gradle files directly up from where I am. I think. No matter.) If I remove that settings.gradle file, then both configurations use the daemon.

Whew. So gradle is allowing files several levels (with gradle-config-voids at intervening levels) up to influence this build.

5

Yes, Gradle looks up the hierarchy for a ‘settings.gradle’, and everything else follows from that. Are you sure that “your” ‘build.gradle’ is even used?

Use ‘–no-search-upward’ to prevent this behavior.

6

Aha. I remember reading something about this. What I did not expect is that higher up configs would influence a project that was not referenced higher up.

But thanks. Yeah, I don’t know now whether my build.gradle file was even being used. The project built, simple as it is.

The --no-search-upward option: can I put that in the ./gradle.properties file?

7

The --no-search-upward option: can I put that in the ./gradle.properties file?

No, but you can achieve the same by putting an empty ‘settings.gradle’ into the project directory.

8

Got it.

Thank you again.