How to actually affect daemon args?

Help/Discuss
1

Hi all! It says in the doc (Build Environment):

org.gradle.jvmargs=(JVM arguments)

Specifies the JVM arguments used for the Gradle Daemon. The setting is particularly useful for configuring JVM memory settings 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:

[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 :frowning:

2

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

1 Like
3

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?

4

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.

5

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.

1 Like
6

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”.

7

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.

8

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?

9

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. :wink:

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.

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. :wink:

10

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.

11

Regarding my title, have a look at Introducing the Gradle Fellowship Program :wink:

1 Like
12

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 (see Use a custom slf4j binding instead of logback. · gradle/gradle@7cbf12b · GitHub) 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 :slight_smile:

13

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.

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.

I had a look at how OutputEventListenerBackedLoggerContext looks currently 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.

14

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 :laughing:

15

just for the consistency… add capability to enable HTTP(s) wire logging · Issue #16353 · gradle/gradle · GitHub

1 Like