Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kill NpmTask when gradle is stopped #238

Open
pmendelski opened this issue Jun 30, 2017 · 11 comments
Open

Kill NpmTask when gradle is stopped #238

pmendelski opened this issue Jun 30, 2017 · 11 comments

Comments

@pmendelski
Copy link

Hi, first of all thanks for a great gradle plugin.

One of my tasks in gradle starts an infinite node task called watch. This task is infinite it means it stops on Ctrl + c. Unfortunately when I kill gradle task the SIGKILL does not propagate to the npm task.

task watchWeb(type: NpmTask, dependsOn: ["installNpmModules"]) {
    args = ["run", "watch"]
}

Terminal execution:

./gradlew watchWeb
<Ctrl+c>
ps aux | grep node
<node task is still running>

Could you tell how to propagate the SIGKILL to npm task?

@rmorrise
Copy link

This issue affects Grails 3.3.0 Angular projects when executed with client:bootRun. After the server is started via the gradle task, stopping the gradle task with Ctrl+C does not stop the node.exe process.

The next time I go to start up the server, I get the "port is already in use" error.

See:
grails-profiles/angular#12

@pmendelski
Copy link
Author

Just to summarize it. There is a workaround for this problem described in #143 (comment)

./gradlew watchWeb --no-daemon
<Ctrl+c>
ps aux | grep node
<node task is not running>

...although IMHO it's a workaround not a solution. That is why I do not close this issue.

@orange-buffalo
Copy link

@mendlik this seems to be a limitation of Gradle daemon (gradle/gradle#1128) and I do not believe this can be fixed within the plugin. Maybe we could communicate the impact to the Gradle team to motivate them to provide a solution here.

@pmendelski
Copy link
Author

@orange-buffalo good idea. I have just created a topic on gradle discuss. Let's start there.

@ayZagen
Copy link

ayZagen commented Mar 20, 2018

any update on this issue ?

@rbuehlma
Copy link

rbuehlma commented Jun 8, 2018

With Gradle 4.8 it should now be possible to fix this issue by implementing the Cancellable Interface:
gradle/gradle#5206

@virgo47
Copy link

virgo47 commented Mar 19, 2019

This bothers us on the CI server (GitLab CI, but it does not matter I guess). If we cancel the build when the Node plugin is running already, it will finish the build anyway. While Gradle does not kill it, CI server waits for it and any next build is pending for many minutes. And we run the builds with --no-daemon, but it does not help in our case - it seems like there is still this one-off daemon: "Daemon will be stopped at the end of the build stopping after processing"

@kristian
Copy link

kristian commented Apr 4, 2019

Same here. We are running a server using an NPM script (npm start). Even by setting --no-daemon the server keeps running after CTRL+C'ing out. A fix for this would be higly appreciated!

@atali
Copy link

atali commented Jul 2, 2020

any update ?

@deepy
Copy link

deepy commented Jul 3, 2020

If anyone is interested in creating a solution to this there's further context in node-gradle/gradle-node-plugin#65 (comment)

But this is something that should be fixed in Gradle and with Java 9+ it's supposedly easy to do.

@PeredurOmega
Copy link

I also recently encountered this issue and I made a custom workaround based on Gradle Shared Build Services (https://docs.gradle.org/current/userguide/build_services.html).
The idea is that the service is attached to npm tasks and kills them properly (i.e. also killing dependents processes) in case the Gradle task is stopped.
If it may be of any use to someone else, I made a small Gradle plugin for it https://github.com/PeredurOmega/GradleNpmPlugin mainly resolving this issue + automatically defining tasks for scripts defined in package.json.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants