https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
j
Copy code
org.gradle.logging.level=info
?
v
GRADLE_OPTS=--info
Or you set the property you mentioned in 
<GRADLE_USER_HOME>/gradle.properties
j
Copy code
GRADLE_OPTS="-Dorg.gradle.daemon=false --info"
➜  android-vente-privee git:(develop) ✗ export GRADLE_OPTS                            
➜  android-vente-privee git:(develop) ✗ ./gradlew build
Unrecognized option: --info
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
v
Ah, stupid me, 
GRADLE_OPTS
of course are the JVM options, not the Gradle options
But well, you already mentioned yourself how to do it 🙂
GRADLE_OPTS="-Dorg.gradle.daemon=false -Dorg.gradle.logging.level=info"
j
I found it after some testing and googling but I didn't know if --info and that flag would have the same effect
after some testing... it seems they do
v
Btw. why should you ever want to generally "disable" the Gradle daemon?
j
because my CI builds are failing with gradle killing the daemon... so I would like to try disabling it... log
Copy code
---- End of the daemon log -----
JVM crash log found: file:///PATH_TO_PROJECT/hs_err_pid53.log
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
v
That will most likely not change anything. Disalbing the daemon does not disable the daemon. 😄
🤣 1
It just disables reuse of the daemon. So your build always runs in a daemon, but that setting controls whether it keeps running after the build finished to run other builds, or whether it is shut down at the end of the build.
j
What is your recommendation ?
Investigate further why the builds are failing at random ?
v
You can try to disable the daemon, I just don't think it will change much. You probably will still have those randomly failing builds and will need to investigate why.
Maybe you indeed need too much RAM, system is out of RAM and the OOM killer kills the daemon. That's almost always the situation when I have seen such behavior with builds running on Linux.
j
it would be great if gradle could just tell me "hey I am getting OOM, give me more RAM" 😛
I will see what I can do. Thanks for the tips
v
That is like saying "It would be great if the victim could have told 'hey, I am getting shot from behind'". 😄
Gradle cannot know when the OOM killer decides to kill it
Maybe you configure the JVM memory to be 6 GiB max while the system only has 4 GiB or similar things.
j
ok, got it
v
Or in older Docker versions Java was only able to see the RAM available in the host machine, not to the actual Docker instance
...
j
I don't think this is the case... the infra in the company is always updated... and I am using the latest https://github.com/alvr/alpine-android/ image
I will try to update to JDK 17, maybe I can get more info with that
v
Or maybe it was with old Java, I don't remember exactly, just that there was an issue. And as it was quite some time ago, I didn't imply that this might be your issue, but that there can easily be issues that would make it impossible to even see that something is going havoc.
e
IIRC you need some relatively recent Java like 17 for cgroups v2 awareness, but v1 awareness was backported to later releases of 8 and 11, or something like that…
👍 1
but I'm not sure how much that matters, I thought Gradle defaulted to setting 
-Xmx512m -XX:MaxMetaspaceSize=256m
or something along those lines
g
Container support in on by default since jdk10 and 8u191
Better to always expose var to pass generic options and set xms/xmx/metaspace though
e
daemon isn't the only thing using memory though, there's tasks and workers that fork (and the kotlin compiler daemon, if you're using kotlin)
https://docs.gradle.org/8.1-rc-1/release-notes.html#better-memory-management should make some of those fit into available memory more reliably
21 Views
Open in Slack
PreviousNext
Powered by