[GRADLE-2655] Gradle Daemon stays open after Eclipse shuts down Created: 25/Jan/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 3


Gradle daemon that is used by the tooling api stays active after the IDE is closed.

1. The daemon consumes some of the system resources and in theory it may not be used after IDE is closed.
2. If the daemon stays active after IDE is closed it may be perceived as 'untidy' by the users.

I had a chat with Adam about this problem. Things we might do:

  • reduce the idle timeout of the daemon (or less likely, expose this setting)
  • add 'finishedWorking()' method to the tooling api that might kill off the daemon or reduce its idle timeout significantly
  • add a way for the daemon to know if it is connected to the IDE
  • there are other options most likely

Reported by Kris initially:

This issue just got raised against the STS gradle tooling: https://issuetracker.springsource.com/browse/STS-3037

I'm not sure how to proceed. I personally think it would be best and logical if the daemon(s) started by STS via tooling API would go away after the STS process itself is terminated.

Alternatively, the tooling API could provide a daemon management API that allows the 'client' to explicitly control the lifetime of the deamons that get started on its behalf, so it can attempt to clean-up after itself and terminate these daemons before it exits.

I could also imagine that the whole design of tooling API and daemon really does't jive with the idea of a tooling API client 'owning' a daemon process or controlling its lifetime. Then the best I can do is probably simply provide a way for STS users to configure the deamon timeout value via a preferences page.

Comment by Gradle Forums [ 25/Jan/13 ]

Hey Kris,

Thanks for reporting! We'll discuss this issue with the team. I'm sure we want to fix this problem.

Comment by Gradle Forums [ 25/Jan/13 ]

Hi Szczepan,
is there a JIRA ticket that tracks this issue?

Comment by Mauro Molinari [ 26/Jan/13 ]

IMHO, a mechanism to "open" the Gradle API as a "master" that causes the daemon to die after the "close" is issued on the API should do the trick. In this way you won't expose the detail of the presence of the daemon to the API client, but you'll make available a hint to the API at initialization time that it may then close the daemon (if nothing else suggests the contrary) at shutdown.

Comment by Dino Lupo [ 05/Oct/15 ]

I know this problem is old, but it's never resolved. I'm working with Eclipse with Buildship plugin and I have some projects with gradle wrapper 2.5 and 2.6. After closing eclipse I can see two daemons, one for each version. They are very resource consuming, is there any way to disable the daemons or to shutdown them after closing eclipse? (I know how to kill them, but it should be automatic)

Comment by Dino Lupo [ 05/Oct/15 ]

After upgrading the plugin everything is fine now. You can close this.


Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:27:50 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.