Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve single-use daemon messaging #2660

Open
big-guy opened this issue Aug 4, 2017 · 13 comments
Open

Improve single-use daemon messaging #2660

big-guy opened this issue Aug 4, 2017 · 13 comments

Comments

@big-guy
Copy link
Member

@big-guy big-guy commented Aug 4, 2017

If JAVA_OPTS or GRADLE_OPTS do not match our defaults for the daemon or the build sets org.gradle.jvmargs, when someone runs with --no-daemon, we fork a single use Gradle daemon.

We print this message:

To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/4.2-20170801184915+0000/userguide/gradle_daemon.html.
Daemon will be stopped at the end of the build stopping after processing

There are a few confusing things here:

  • "the JVM settings" -- which "JVM settings" are these?
  • We say "Daemon will be stopped at the end of the build" and "consider using the daemon"

I think we should do these things:

  1. Reword the "single use daemon" message. Something like "A single use Gradle daemon will be used because the current JVM is incompatible. Learn more: ". We should remove the technical "Daemon will be stopped at the end of the build stopping after processing" message.
  2. The Gradle daemon chapter should be reviewed. There is still some language that appears to assume the daemon is disabled by default.
  3. We should add a new "single user daemon" section to the Gradle daemon chapter. It should describe in more detail why a single use daemon is created. We can also include information about how to avoid it.
  4. We should fix the build-scan plugin so that it does not report the single use daemon as a good thing: #2597
@adammurdoch

This comment has been minimized.

Copy link
Member

@adammurdoch adammurdoch commented Aug 4, 2017

I would think about removing the single use daemon, and do one of the following:

  1. Warn when the JVM args defined in your environment ($JAVA_OPTS/$GRADLE_OPTS/command-line/~/.gradle/gradle.properties/whatever) are not compatible with those specified in the build definition (in gradle.properties/whatever), but go ahead with using the definition from the environment. Also provide some diagnostics, such as where the environment definition came from and what it resolved to, where the build definition came from and what it resolved to, and in which ways they are incompatible.
  2. Or, fail in the above case, and tell you how to proceed.
  3. Or, warn but go ahead with using the definition from the build.
  4. Or, silently prefer whatever is specified in the environment.
  5. Or, silently prefer whatever is specified in the build definition.
@adammurdoch

This comment has been minimized.

Copy link
Member

@adammurdoch adammurdoch commented Aug 4, 2017

We should also consider making this consistent with what happens when you run with the daemon and the build definition and environment definition conflict with each other.

@adammurdoch

This comment has been minimized.

Copy link
Member

@adammurdoch adammurdoch commented Aug 4, 2017

actually, 'no single use daemon' and 'prefer the build definition' won't work together, scratch those options.

@Stono

This comment has been minimized.

Copy link

@Stono Stono commented Jan 8, 2019

I just stumbled across this btw, we don't use the gradle daemon because we're building apps in docker containers, so single use is what we want. Would be great if we could suppress the warning.

@nngo

This comment has been minimized.

Copy link

@nngo nngo commented Jan 14, 2019

My GRADLE_OPTS has -Dorg.gradle.daemon=false to disable the daemon for a CI build, how do I disable the To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: ... message?

Update:
Looks like I can use pass --quiet flag to suppress the above message, but it also suppresses other useful output such as the tasks that are executed in the build.

@arnaud-deprez

This comment has been minimized.

Copy link

@arnaud-deprez arnaud-deprez commented Jul 22, 2019

I would think about removing the single use daemon, and do one of the following:

1. Warn when the JVM args defined in your environment ($JAVA_OPTS/$GRADLE_OPTS/command-line/~/.gradle/gradle.properties/whatever) are not compatible with those specified in the build definition (in `gradle.properties`/whatever), but go ahead with using the definition from the environment. Also provide some diagnostics, such as where the environment definition came from and what it resolved to, where the build definition came from and what it resolved to, and in which ways they are incompatible.

2. Or, fail in the above case, and tell you how to proceed.

3. Or, warn but go ahead with using the definition from the build.

4. Or, silently prefer whatever is specified in the environment.

5. Or, silently prefer whatever is specified in the build definition.

I'm definitely for option 1.

If the user says

I don't want a gradle daemon by setting org.gradle.daemon=false or passing --no-daemon

Then gradle should not create a daemon nor a fork but notify him what settings it resolves in case of conflicts.

@sdeleuze

This comment has been minimized.

Copy link
Contributor

@sdeleuze sdeleuze commented Nov 22, 2019

Please allow us to remove this irritating warning. It is perfectly reasonable for users to disable Gradle daemon via org.gradle.daemon=false and prefer to wait a little bit longer when Gradle starts. No need to punish us ;-)

@queryholic

This comment has been minimized.

Copy link

@queryholic queryholic commented Mar 4, 2020

please fix this bug quickly :)

@avonengel

This comment has been minimized.

Copy link

@avonengel avonengel commented Mar 20, 2020

Could someone point out which settings need to match so that Gradle does not fork a single-use daemon?
Example:
I created a new project through IntelliJ's wizard with Kotlin DSL:

plugins {
    kotlin("jvm") version "1.3.70"
}

group = "org.example"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    implementation(kotlin("stdlib-jdk8"))
}

tasks {
    compileKotlin {
        kotlinOptions.jvmTarget = "1.8"
    }
    compileTestKotlin {
        kotlinOptions.jvmTarget = "1.8"
    }
}

When I run this inside an openjdk:8-alpine container, I get that message. I have no clue why that is, though...

@chanseokoh

This comment has been minimized.

Copy link

@chanseokoh chanseokoh commented Mar 20, 2020

I cannot figure out the condition that is triggering a single-use daemon. I set neither JAVA_OPTS, GRADLE_OPTS, nor org.gradle.jvmarg. I don't have ~/.gradle/gradle.properties or gradle.properties in my project. Nothing I pass on the command line except --no-daemon.

I do need to disable the daemon, but I have no clue as to how.

@ndw

This comment has been minimized.

Copy link

@ndw ndw commented Mar 23, 2020

If I've explicitly disabled the daemon, could you please not print out that damned "Please consider using the daemon" message and all other messages related to it. I don't want to use it. On several occasions when I tried to use it, I got build errors or incorrect builds that worked just fine if I disabled it. I have neither the experience with gradle nor the interest necessary to help debug the problems, nor do I especially care about making the builds faster. I just want them to be correct. And I don't need to be asked to use it every time because the answer is always going to be "no".

@chanseokoh

This comment has been minimized.

Copy link

@chanseokoh chanseokoh commented Mar 23, 2020

Regarding #2660 (comment), here's what worked as a workaround.

First, run with --no-daemon --debug and the check what JVM arguments are being used. They will be shown at the beginning of the output.

14:27:17.775 [INFO] [org.gradle.internal.nativeintegration.services.NativeServices] Initialized native services in: /home/chanseok/.gradle/native
14:27:17.957 [LIFECYCLE] [org.gradle.launcher.daemon.client.SingleUseDaemonClient] To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.2.1/userguide/gradle_daemon.html.
14:27:17.987 [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon args: [/home/chanseok/jdk1.8.0_171/bin/java, -XX:MaxMetaspaceSize=256m, -XX:+HeapDumpOnOutOfMemoryError, -Xmx512m, -Dfile.encoding=UTF-8, -Duser.country=US, -Duser.language=en, -Duser.variant, -cp, /home/chanseok/gradle-5.2.1/lib/gradle-launcher-5.2.1.jar]

In my case, they were

-XX:MaxMetaspaceSize=256m
-XX:+HeapDumpOnOutOfMemoryError
-Xmx512m
-Dfile.encoding=UTF-8
-Duser.country=US
-Duser.language=en
-Duser.variant

Then, use the exact same arguments via GRADLE_OPTS on the command line. That is,

$ GRADLE_OPTS="-XX:MaxMetaspaceSize=256m
               -XX:+HeapDumpOnOutOfMemoryError
               -Xmx512m
               -Dfile.encoding=UTF-8
               -Duser.country=US
               -Duser.language=en
               -Duser.variant" \
    ./gradlew --no-daemon --debug

Now it runs without using a daemon.

10:23:22.608 [INFO] [org.gradle.internal.nativeintegration.services.NativeServices] Initialized native services in: /home/chanseok/.gradle/native                                                                  
10:23:23.281 [INFO] [org.gradle.internal.work.DefaultWorkerLeaseService] Using 8 worker leases.                                                                                                                    
10:23:23.337 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for fileHashes, path /home/chanseok/.gradle/caches/5.1/fileHashes/fileHashes.bin, access org.gradle.cache.internal.DefaultCacheAccess@4aa83f4f                                                                                                                                                                                                 
@chanseokoh

This comment has been minimized.

Copy link

@chanseokoh chanseokoh commented Mar 23, 2020

Actually, looks like I don't need to pass -D arguments. The following worked in my case.

$ GRADLE_OPTS="-XX:MaxMetaspaceSize=256m
               -XX:+HeapDumpOnOutOfMemoryError
               -Xmx512m" ./gradlew --no-daemon --debug

However, removing -Xmx512m causes Gradle to use a single-use daemon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.