# How to actually affect daemon args? **URL:** \ **Category:** Help/Discuss\ **Created:** [February 16, 2021, 8:07pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053 "2021-02-16T20:07:43Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 16, 2021, 8:07pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/1 "2021-02-16T20:07:43Z")
Hi all! It says in the doc ([Build Environment](https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties)): `org.gradle.jvmargs=(JVM arguments)` Specifies the JVM arguments used for the Gradle Daemon. The setting is particularly useful for [configuring JVM memory settings](https://docs.gradle.org/current/userguide/build_environment.html#sec:configuring_jvm_memory) for build performance. This does not affect the JVM settings for the Gradle client VM. However, no matter what I put here, it does not seem to affect in the slightest the JVM args for a created daemon, see for example: `org.gradle.jvmargs=-Djava.util.logging.config.file=$HOME/myapp/logging.properties` `gradlew properties --no-daemon -d` logs: ```gradle [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] Using daemon args: [C:\Program Files\Java\jdk1.8.0_144\bin\java.exe, -Dfile.encoding=windows-1251, -Duser.country=US, -Duser.language=en, -Duser.variant, -cp, C:\Users\kiril\.gradle\wrapper\dists\gradle-6.8.2-bin\5nlkemqlnno2amj7d1mfn69bt\gradle-6.8.2\lib\gradle-launcher-6.8.2.jar] 2021-02-16T22:04:35.863+0200 [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] Starting daemon process: workingDir = C:\Users\kiril\.gradle\daemon\6.8.2, daemonArgs: [C:\Program Files\Java\jdk1.8.0_144\bin\java.exe, -Dfile.encoding=windows-1251, -Duser.country=US, -Duser.language=en, -Duser.variant, -cp, C:\Users\kiril\.gradle\wrapper\dists\gradle-6.8.2-bin\5nlkemqlnno2amj7d1mfn69bt\gradle-6.8.2\lib\gradle-launcher-6.8.2.jar, org.gradle.launcher.daemon.bootstrap.GradleDaemon, 6.8.2] [QUIET] [org.gradle.api.tasks.diagnostics.internal.ReportGenerator] org.gradle.jvmargs: -Djava.util.logging.config.file=$HOME/myapp/logging.properties ``` I am in despair… I’d like to be able to set system properties _for the actual danned JVM process that runs the build_ !!! and I can’t figure out how to do it. I’ve tried also `JAVA_OPTS`, `GRADLE_OPTS` and even `_JAVA_OPTIONS`. None seem to affect that creepy Daemon process arguments ☹ ---
**Author:** ![Chris\_Dore](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/chris_dore/32/7592_2.png) [@Chris\_Dore](https://discuss.gradle.org/u/Chris_Dore)\ **Post date:** [February 17, 2021, 6:01am UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/2 "2021-02-17T06:01:45Z")
Gradle can re-use daemons that are compatible. Only certain, effectively immutable, JVM system properties/attributes will cause daemon incompatibility and impact a daemon’s actual commandline. All other system properties are handled during runtime of the daemon. When setting/changing a non-immutable system property, there is no need for a daemon process to be launched with that commandline. Instead, the daemon morphs its system properties to that which are needed by the currently executing build. See the daemon FAQ for more info. [https://docs.gradle.org/current/userguide/gradle\_daemon.html#sec:why\_is\_there\_more\_than\_one\_daemon\_process\_on\_my\_machine](https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:why_is_there_more_than_one_daemon_process_on_my_machine) ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 6:17am UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/3 "2021-02-17T06:17:08Z")
so you say it still picks up those `org.gradle.jvmargs` arguments even though daemon is not getting those via it’s args on startup? Ok, but at _which_ stage does it pick it up? How could I prove/confirm that they are in effect _before_ JUL logging configuration for the `maven-publish` plugin is initialized? ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 7:29am UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/4 "2021-02-17T07:29:36Z")
I’ve just run a quick check and indeed, at the `doFirst` (for any task, it seems) closure execution time those system properties are being defined and visible. Still not sure why they do not seem to have any impact on the logging, but that might be due to unrelated processes, like JUL logging is disabling itself because some other logging implementations are found on the classpath or something like that. ---
**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\ **Post date:** [February 17, 2021, 11:36am UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/5 "2021-02-17T11:36:58Z")
JUL does not disable just because there might be some other logging framework, especially as JUL logging would then be lost as long as there is no bridge to the other logging framework. The problem is more likely that the dynamic handling of the system properties is too late for JUL to be affected. Iirc this property needs to be set before the first JUL call is done because at initialization time it is evaluated and after that not anymore. So what you can do is, you can use `JAVA_TOOL_OPTIONS` environment variable. This environment variable is picked up by any started Java process automatically, so you should be able to specify your system property there, as long as you make sure a new daemon is actually started, for example with the `--no-daemon` option you used already. ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 12:22pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/6 "2021-02-17T12:22:18Z")
that’s a very good suggestion, I have not heard about this env variable before, thanks a lot. Actually it might also be due to the fact that Gradle does not actually use `org.apache.http` dependency, it uses some “internal” classes that have similar names, but actually don’t log anything at all, or at least that was the impression I’ve got while debugging gradle build in IntelliJ. So that’s a separate discussion probably, “how do I enable HTTP wire dumping for Gradle “internal” HTTP calls, for example the ones that `maven-publish` plugin is executing”. ---
**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\ **Post date:** [February 17, 2021, 1:18pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/7 "2021-02-17T13:18:20Z")
HTTP wire dumping? Just use WireShark to capture the HTTP traffic. Or configure a proxy like Fiddler where you can see the HTTP request sent through it. ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 1:27pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/8 "2021-02-17T13:27:45Z")
I think that with WireShark I will only be able to see encrypted HTTPS traffic. And with Fiddler, installing a fake certificate is also not really feasible in a corporate environment without administrator permissions. Is this official Gradle position, that wire dump is not possible for Gradle components traffic? ---
**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\ **Post date:** [February 17, 2021, 1:32pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/9 "2021-02-17T13:32:19Z")
> [@62mkv](#): > > I think that with WireShark I will only be able to see encrypted HTTPS traffic. Of course, unless you can get hold of the private key that is used to encrypt it, then WireShark can decrypt it. You said HTTP, not HTTPS. 😉 > [@62mkv](#): > > And with Fiddler, installing a fake certificate is also not really feasible in a corporate environment without administrator permissions. That’s perfectly feasible for Java, as there you don’t need asministrator permissions, you just need to configure a custom trust store via system properties and it should work fine. > [@62mkv](#): > > Is this official Gradle position, that wire dump is not possible for Gradle components traffic? I’m not a Gradle official, just a community member like you. It could well be that there is logging you can enable, I just am not aware of it and didn’t feel like searching for you, but just provided you with alternatives how to do it. 😉 ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 1:45pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/10 "2021-02-17T13:45:40Z")
Ok, understood, thanks for your support! I was just a bit confused with the “Gradle Fellow” title you have here. it still feels though as if having to configure a custom truststore, custom proxy, etc, is way more involved than it normally should be. So maybe someone at Gradle will notice this, let’s see. ---
**Author:** ![Vampire](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/vampire/32/9082_2.png) [@Vampire](https://discuss.gradle.org/u/Vampire)\ **Post date:** [February 17, 2021, 3:07pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/11 "2021-02-17T15:07:40Z")
Regarding my title, have a look at [Introducing the Gradle Fellowship Program](https://blog.gradle.org/gradle-fellowship) 😉 ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 17, 2021, 3:54pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/12 "2021-02-17T15:54:46Z")
Just for history, probably: it looks that wire and headers logging is disabled intentionally, at least in the 6.8.2 and latest master it seems to be no-op’d and it’s not at clear how to re-enable them. the first commit I was able to identify, to contain thus behavior is [Use a custom slf4j binding instead of logback. · gradle/gradle@7cbf12b · GitHub](https://github.com/gradle/gradle/commit/7cbf12b39d32c56a0b051258026e5b3d4df03efa) (see [Use a custom slf4j binding instead of logback. · gradle/gradle@7cbf12b · GitHub](https://github.com/gradle/gradle/commit/7cbf12b39d32c56a0b051258026e5b3d4df03efa#diff-c996d988bda5361aab1c6670ff9a56ccb9da738c9eae3b46c3ca7ae2a920e0cb)) but it’s not clear which issue was covered and the motivation for this change. Commit message does not mention anything at all about those wire loggings. so probably there was some background discussion going on at the time, which unfortunately is not reflected anywhere (or at least i am too inexperienced to be able to find it) Software archeology fans, please help 🙂 ---
**Author:** ![erdi](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/erdi/32/24_2.png) [@erdi](https://discuss.gradle.org/u/erdi)\ **Post date:** [February 26, 2021, 2:55pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/13 "2021-02-26T14:55:00Z")
Hi @62mkv! This thread has been brought to my attention by @Vampire, because you linked to a commit I am an author of. The commit that you have identified is unfortunately not the source of the code which disables `org.apache.http.wire` logging - if you take a closer look at the diff then you will notice that the code has been simply moved from [`LogbackLoggingConfigurer`](https://github.com/gradle/gradle/commit/7cbf12b39d32c56a0b051258026e5b3d4df03efa#diff-8de53d9ba14d3f90f779e557a0c6e65b03400f0f8b2400109c700b9e0aa6104e). I don’t know for sure but I suspect that due to logging to `org.apache.http.wire` being extremely verbose it is disabled by default because it would dwarf any logging at `DEBUG` level which you can [turn on by using `--debug` command line switch](https://docs.gradle.org/current/userguide/logging.html#sec:choosing_a_log_level). I had a look at how [`OutputEventListenerBackedLoggerContext` looks currently](https://github.com/gradle/gradle/blob/master/subprojects/logging/src/main/java/org/gradle/internal/logging/slf4j/OutputEventListenerBackedLoggerContext.java) and it looks like a no-op logger is registered for `org.apache.http.wire` and that there is no obvious way to stop if from happening. The only thing that comes to my mind would be opening a github issue asking for this to be opened up. ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [February 26, 2021, 3:44pm UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/14 "2021-02-26T15:44:46Z")
thanks! That’s what I’ve figured, as well (that that was _NOT_ the original commit to contain that disabling). Will see… If I have energy enough to raise an issue 😆 ---
**Author:** ![62mkv](https://avatars.discourse-cdn.com/v4/letter/6/58956e/32.png) [@62mkv](https://discuss.gradle.org/u/62mkv)\ **Post date:** [March 1, 2021, 10:44am UTC](https://discuss.gradle.org/t/how-to-actually-affect-daemon-args/39053/15 "2021-03-01T10:44:47Z")
just for the consistency… [add capability to enable HTTP(s) wire logging · Issue #16353 · gradle/gradle · GitHub](https://github.com/gradle/gradle/issues/16353)