Gradle
  1. Gradle
  2. GRADLE-1594

Tooling API spawning 'runaway' daemon?

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Resolution: Unresolved
    • Affects Version/s: 1.0-milestone-3
    • Fix Version/s: None

      Description

      When I run some Gradle action/command (doesn't really matter what) from STS (uses the Gradle tooling API milestone-3) it starts an external process (I'm assuming this is a gradle daemon).

      Sometimes this process gets busy with a very long running operation. If I try to exit Eclipse/STS it won't let me until this operation is finished. It is then very tempting to forcibly kill Eclipse/STS.

      Unfortunately, when you do that the Daemon is left running and I don't think there's a way for me to shut it down (except kill it using a kill command on in the os commandline) "kill -9 <process-id>"

      I also tried running "gradle --stop" on the commandline but the process was left running (and it is telling me the Daemon isn't running).

        Activity

        Hide
        Kris De Volder
        added a comment -

        I also tried to stop daemon with command "gradle --stop". (I still have the two daemons running, now).

        First time I tried it it printed
        kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop
        Stopping
        Gradle daemon stopped.

        But when I check "ps -fu kdvolder | grep wrapper" I see that both daemon processes are still there after that.

        Then I type try "gradle --stop" again and it tells me:
        Gradle daemon is not running.

        But again "ps ..." the processes are both still there.

        Now... I run another command from STS and I now have 3 daemon processes sitting there.

        Conclusion: this is probably not yet fixed.

        PS: I did do something a bit 'nasty'. I deleted the .gradle folder. As I was trying to make the commands take longer and do more work. Maybe that could be what confused the daemons.

        Show
        Kris De Volder
        added a comment - I also tried to stop daemon with command "gradle --stop". (I still have the two daemons running, now). First time I tried it it printed kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop Stopping Gradle daemon stopped. But when I check "ps -fu kdvolder | grep wrapper" I see that both daemon processes are still there after that. Then I type try "gradle --stop" again and it tells me: Gradle daemon is not running. But again "ps ..." the processes are both still there. Now... I run another command from STS and I now have 3 daemon processes sitting there. Conclusion: this is probably not yet fixed. PS: I did do something a bit 'nasty'. I deleted the .gradle folder. As I was trying to make the commands take longer and do more work. Maybe that could be what confused the daemons.
        Hide
        Kris De Volder
        added a comment -

        The third daemon that just got started, aparantly also isn't running:

        kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop
        Gradle daemon is not running.
        

        This is odd, because it just succesfully built a gradle model for my STS.

        Show
        Kris De Volder
        added a comment - The third daemon that just got started, aparantly also isn't running: kdvolder@bun2:~/commandline-dev/gradle-plugins$ gradle --stop Gradle daemon is not running. This is odd, because it just succesfully built a gradle model for my STS.
        Hide
        Kris De Volder
        added a comment -

        Some positive news:

        I tried the following:

        • start STS
        • start executing a gradle command
        • kill STS while the command is running

        => it looks like the daemon executing this command is immediately terminated.

        So I am no longer able to get into a situation where I accumulate dead daemons by killing processes that are using the daemon "in midflight".

        Show
        Kris De Volder
        added a comment - Some positive news: I tried the following: start STS start executing a gradle command kill STS while the command is running => it looks like the daemon executing this command is immediately terminated. So I am no longer able to get into a situation where I accumulate dead daemons by killing processes that are using the daemon "in midflight".
        Hide
        Adam Murdoch
        added a comment - - edited

        @Kris, thanks for this feedback. It's excellent stuff. Given what you've seen, let's leave this issue open.

        I've raised some other issues based on what you've mentioned:

        GRADLE-1890 - don't leave more than one idle daemon running.
        GRADLE-1891 - consider daemons from all Gradle versions for daemon management (timeouts and gradle --stop, etc).

        Then there's:

        GRADLE-1771/GRADLE-1240 - to reduce the memory impact of each daemon instance.
        GRADLE-1763 - daemon management should deal with ~/.gradle being deleted.

        Our plan is to fix 1890, 1771/1240 and 1765 fairly soon. We're holding off on 1891 for a bit, until the client - daemon protocol stabilises a little.

        Show
        Adam Murdoch
        added a comment - - edited @Kris, thanks for this feedback. It's excellent stuff. Given what you've seen, let's leave this issue open. I've raised some other issues based on what you've mentioned: GRADLE-1890 - don't leave more than one idle daemon running. GRADLE-1891 - consider daemons from all Gradle versions for daemon management (timeouts and gradle --stop, etc). Then there's: GRADLE-1771 / GRADLE-1240 - to reduce the memory impact of each daemon instance. GRADLE-1763 - daemon management should deal with ~/.gradle being deleted. Our plan is to fix 1890, 1771/1240 and 1765 fairly soon. We're holding off on 1891 for a bit, until the client - daemon protocol stabilises a little.
        Hide
        Kris De Volder
        added a comment -

        Sounds good. I also hope you'll consider a more reasonable timeout... 3 hours seems a bit long

        Another thing worth considering is that my point of view is that of an interactive user who 'owns' the machine he's using.

        Things may be different if you consider scenarios of running builds on something like a shared build server.

        Show
        Kris De Volder
        added a comment - Sounds good. I also hope you'll consider a more reasonable timeout... 3 hours seems a bit long Another thing worth considering is that my point of view is that of an interactive user who 'owns' the machine he's using. Things may be different if you consider scenarios of running builds on something like a shared build server.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kris De Volder
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: