Why can't gradle correctly exit processes that it ...
# community-support
b
Why can't gradle correctly exit processes that it starts in
Exec
when the task receives
Ctrl+C
, but everything else can? I have found around 220 reports of issues related to this, since at least 2013 What am I not understanding?
j
Is this about (grand)children processes not being stopped? Because I am trying to push this change to make it work now that Gradle is no longer limited to pre-Java9 APIs https://github.com/gradle/gradle/pull/33596 The process directly started by Gradle should be stopped. At least that's what I saw in my recent experiments. Or which issues are there related to this? I would be interested to know.
b
thanks for taking a look at this i am running gradle 9 and ticket this here: https://github.com/gradle/gradle/issues/34095 is there any easy way to run gradle from
master
to test?
any gradle Exec task which calls e.g.
next dev
will cause this to occur
j
This looks like it may be the same issue as there are subprocesses involved. The long standing issue on the topic is https://github.com/gradle/gradle/issues/7603 I believe.
b
i wish there were a workaround. i will accept literally anything at this point. this problem is the bane of my existence
yes but why
why is gradle the only project that has trouble exiting things
and why is there no workaround? it only has to work work for "Ctrl+C" on two platforms, macOS and Windows, for
Exec
that doesn't complete, and nothing more
can I patch
destroyProcessTree();
into my Exec tasks somehow?
j
Maybe it was always postponed, because it was not "that easy" to implement for all operating systems with Java 8. If you want to try the fix from my branch, you can clone the PR branch. And build a local Gradle installation: https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md#install-gradle-locally Then test if it fixes your issue. Would be interesting to know!
I think there is no way (unfortunately) to patch that into an existing Gradle installation.
b
thanks for implementing this fix, i'm testing it now on windows, there are no process trees, there are only job objects does the JVM use job objects to emulate a process tree?
i don't know. this is like a hair on fire problem. how can the gradle team ignore it for 11 years...
j
I think so, but I do not know the details. As I am not working on Windows very often. But getting it working on windows is also my primary motivation. The test I wrote in the PR should also verify that it works on Windows. But I am not sure if the standard contributor pipeline is running things on Windows (probably not). Have to wait until someone sends it through the whole pipeline.
b
Copy code
āžœ  āœ— ./gradlew install -Pgradle_installPath=~/Documents/gradle-9 -Porg.gradle.java.installations.auto-detect=false
Starting a Gradle Daemon (subsequent builds will be faster)
Daemon JVM discovery is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Cannot find a Java installation on your machine (Mac OS X 15.3.2 aarch64) matching: {languageVersion=17, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}. Toolchain auto-provisioning is not enabled.
i'm getting pretty fatigued out by this yak shave
alright i'm making some progress...
false hope
@Jendrik Johannes this does fix the issue
šŸŽ‰ 1
j
Feel free to comment on the PR that you tested it manually on Windows and that it would fix the issue you reported. This may help to give it more priority. Thanks.