# What to do about "Gradle Daemon stays open after Eclipse shuts down"? **URL:** \ **Category:** Old Forum Archive\ **Created:** [November 13, 2012, 6:11pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515 "2012-11-13T18:11:00Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![kris\_de\_volder](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/kris_de_volder/32/514_2.png) [@kris\_de\_volder](https://discuss.gradle.org/u/kris_de_volder)\ **Post date:** [November 13, 2012, 6:11pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/1 "2012-11-13T18:11:00Z")
This issue just got raised against the STS gradle tooling: [https://issuetracker.springsource.com/browse/STS-3037](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. Any thoughts on these three options (or some other ideas I haven’t thought of yet)? Kris ---
**Author:** ![Szczepan\_Faber](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/szczepan_faber/32/213_2.png) [@Szczepan\_Faber](https://discuss.gradle.org/u/Szczepan_Faber)\ **Post date:** [November 14, 2012, 7:50am UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/2 "2012-11-14T07:50:00Z")
Hey Kris, Thanks for reporting! We’ll discuss this issue with the team. I’m sure we want to fix this problem. ---
**Author:** ![mauromol](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/mauromol/32/994_2.png) [@mauromol](https://discuss.gradle.org/u/mauromol)\ **Post date:** [January 22, 2013, 7:46pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/3 "2013-01-22T19:46:00Z")
Hi Szczepan, is there a JIRA ticket that tracks this issue? ---
**Author:** ![Szczepan\_Faber](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/szczepan_faber/32/213_2.png) [@Szczepan\_Faber](https://discuss.gradle.org/u/Szczepan_Faber)\ **Post date:** [January 25, 2013, 3:28pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/4 "2013-01-25T15:28:00Z")
Exported to jira. We’ll definitely want to fix this problem at some point. ---
**Author:** ![Sergei\_Bombic](https://avatars.discourse-cdn.com/v4/letter/s/b9bd4f/32.png) [@Sergei\_Bombic](https://discuss.gradle.org/u/Sergei_Bombic)\ **Post date:** [February 10, 2013, 3:26pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/5 "2013-02-10T15:26:00Z")
This clears up why with each executing of jettyRunWar/jettyStop I was getting 2 additional unresponsive jvms in process list. It only happens when I do so from STS, but works perfectly from command prompt. ---
**Author:** ![kris\_de\_volder](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/kris_de_volder/32/514_2.png) [@kris\_de\_volder](https://discuss.gradle.org/u/kris_de_volder)\ **Post date:** [February 12, 2013, 5:30pm UTC](https://discuss.gradle.org/t/what-to-do-about-gradle-daemon-stays-open-after-eclipse-shuts-down/6515/6 "2013-02-12T17:30:00Z")
Sergei… Right, because on command line by default Gradle isn’t using the gradle daemon.