Gradle logging hygiene

[rmorrise]

Implement log hygiene in Gradle's default configuration, as described in:
https://discuss.gradle.org/t/gradle-daemon-produces-a-lot-of-logs/9905

Expected Behavior

Gradle should be configured out-of-the-box with a rolling file appender or similar mechanism so that the daemon logs are periodically cleaned up.

Current Behavior

Gradle produces daemon logs in a hidden user directory. These logs accumulate over time and are never cleaned up.

Context

My Grails build was leaking daemon processes, contributing to low disk space on C:
(The daemon process leak is beyond the scope of this feature request.)

Steps to Reproduce (for bugs)

Not a bug.

Your Environment

• Build scan URL:

Win7 x64, Grails 3.3.0, Gradle 3.4.1, Groovy 2.4.7, JVM 1.8.0_66

[staffanf]

I just found 20 Gb worth of deamon logs in ~/.gradle. Some of these were 4Gb full of System.out output some debug task I ran some month ago.
Would be nice with some kind of log rotation at least.

[agilob]

I just removed 89Gb of text files in .gradle/daemon/4.7 -.-'
There must be a way to stop this, it generates billions of writes to disks, that's unhealthily.

[lostcart]

I just deleted 160GB after Android studio complained I didn't have enough disk space - 1 day later and log files are at 2.4GB - this is insane . (I also have over 9GB of memory used from AS, but that's another issue :D)

[ghost]

+1

[petarmarijanovicfive]

+1

I deleted 100+GB.

This is a big issue. Gradle shouldn't log anything to a separate file unless it is specifically configured to do so.

[coderkun]

It looks like the log level in these files is DEBUG. If it is possible to configure the log level the Gradle daemon is using, it will reduce the amount of logs greatly.

[chaosky]

It looks like the log level in these files is DEBUG. If it is possible to configure the log level the Gradle daemon is using, it will reduce the amount of logs greatly.

It looks like it's hardcoded in DaemonMain.java#L192, probably providing a System.property such as -Dorg.gradle.daemon.logging.level=(quiet,warn,lifecycle,info,debug) to control it.

@fbe @rmorrise

[lingyfh]

org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)

gradle Build Environment config url
choosing_a_log_level

[kevinstembridge]

+1

[brokenalarms]

Any progress on this? This fills my hard drive and blocks work without warning until I investigate and fix each time. Would have considered this a major issue due to it impacting the entire user's system as a side effect.

[JacquesLeRoux]

The problem is that none of the log levels is able to render nothing. I don't want to have to clean by hand my production VM every now an then :/
I'd like to have an option to mute the daemon log!

[bugs84]

It would be great if there was some "good default" like "delete older than a month". "Do not eat up the whole disk by default"
Imagine: My colleague setup builds. And after some time someone else has to solve "Why disk is full and everything is broken :("
(and someone else knows nothing about Gradle)

[Dave562CZ]

+1

[cyberpwnn]

+1

[TigerPhenix]

+1

[markrmiller]

+1 - jesus this is insane and I can't believe it's still going.

[chylex]

Any updates on this? I just deleted several GB of not just logs, but also some so-called "temporary" files Gradle never cleaned up..

[p4paul]

+1
Just removed 3.1GB of logs with find ~/.gradle -name *.out.log -exec rm {} \;

[charlesritchea]

This doesn't have to be automatic, just a command like docker system prune

[JacquesLeRoux]

Not everybody use docker, OK can be any such command, but better be safe than sorry with an automated option. OK could be a any such command runs by a cron job. But sincerely it would much more easy with an embedded documented function for that rather than being surprised one day with a disk full!

[winterbe]

We just deleted 60+GB on our CI agents after figuring this out, multiple hundreds of GB in total space. We don't use docker, so we have to setup a cleanup job I guess. An easy build-in option to prune logs is highly appreciated. I don't think many people outside of the Gradle team even look at those logs.

[slPerryRhodan]

Default tasks for cleaning the logs and cache would be very nice.

[tkrah]

If this is going to be fixed - please also have a look in the "/tmp" directory for the kotlin-daemon log files (kotlin daemon is spawned by gradle if kotlin is used e.g. in buildSrc), those are gathering there too:

/tmp/kotlin-daemon.2022-07-11.10-04-03-480.00.log

and so one for each daemon and each day - on CI this is gathering up fast.

[ebrandsberg]

15GB of logs here... All I can say is wtf? No production code should have this type of log issue today, and when opened up how many years ago? To still be a problem?

[nhouser9]

it's fully ridiculous that this isn't fixed. just found out this was taking up 20% of my SSD. ideal would be providing a default that makes any sense. in lieu of that, please at least make this configurable.

[pwagland]

We just ran across this same issue, a month into building, on our CI server we had 40G of logs in this directory, almost a terabyte across the CI landscape…

[shollander]

Why is this so hard to fix? This issue has been open for for over 5 years already and I don't even see any response from the Gradle team.

[jbartok]

Thank you for your interest in Gradle!

This feature request is in the backlog of the relevant team and is prioritized by them.

[JacquesLeRoux]

Good news, thanks @jbartok :)

[sreich]

this bug just killed my build server...

rule #1 of ever writing code using a temp dir is the owning app must clean itself up...if it doesn't, then it's broken. i'm shocked to see that it's been so many years, going back many gradle versions, and this has still been an issue...but at least it's getting attention now

in my case, it is kotlin-daemon.log, so those will hopefully be addressed in the upcoming fix...but it looks like there are also junit files and other things in the tmpdir that it may not be cleaning up (cannot confirm that bit)

until then, looks like we're going to have to write a cleanup job hack for this 1 application so it doesn't break the build server for everyone every month

[tanranran]

please Request repair, I am especially afraid that the computer will break down

[mgroth0]

My builds have been having strange performance issues lately. And after a deep dive with a profiler, I finally found out it was because of this.

The Gradle daemon logger is creating 1GB logs for some of my larger builds. I have hundreds of subprojects, and gradle doesn't seem to account for this level scaling with its daemon logger. Some of my builds, the daemon logger is the primary consumer of CPU.

Also, I just deleted 137 GB of logs. Good thing I caught this before I filled up my hard drive, which can be a huge risk. I once almost lost all my files on a computer where I accidentally filled up the hard drive to max.

I request the following:

• Log rotations be default. Manage the daemon log folder, detect if it is above a certain size (configurable, default maybe 10 GB) and delete old logs to keep it under this maximum
• Better documentation on daemon logging, since it has a significant impact on a large number of users and poses serious risks if mismanaged
• Allow configuring the daemon log level with a property.
• Set daemon logging to info or warn by default. Setting it to debug by default is excessive and significantly harms performance on large builds.

[mgroth0]

Is there any way to configure the daemon log level currently? Any workaround?

[mgroth0]

In just a single simple build where I run one task (a no-op task that does nothing), I produce a daemon log file with hundreds of thousands of lines like this:

BuildEvent[event=org.gradle.internal.build.event.types.DefaultOperationFinishedProgressEvent@7e01373c]
2023-09-21T14:18:16.120-0400 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 29: dispatching BuildEvent[event=org.gradle.internal.build.event.types.DefaultOperationStartedProgressEvent@75bb0704]
2023-09-21T14:18:16.120-0400 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 29: dispatching