# Run finalizedBy when task is interrupted (ctrl-c) - continued from old forum

**URL:** <https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c-continued-from-old-forum/12036>\
**Category:** Bugs\
**Created:** [October 5, 2015, 11:13pm UTC](https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c-continued-from-old-forum/12036 "2015-10-05T23:13:57Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rjernst](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/rjernst/32/2812_2.png) [@rjernst](https://discuss.gradle.org/u/rjernst)\
**Post date:** [October 5, 2015, 11:13pm UTC](https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c-continued-from-old-forum/12036/1 "2015-10-05T23:13:57Z")

</div>

Continuing the discussion from [Run finalizedBy when task is interrupted (ctrl-c)](https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c/3084):

> [@Run finalizedBy when task is interrupted (ctrl-c)](https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c/3084/1):
>
> So I don’t know if this is even possible in the JVM in general, to be honest, but figured I’d ask… Is it possible to run a finalizedBy if a subsequent operation has been interrupted with a ctrl-c? I think this would mean binding a task to a ‘System’'s shutdown hook. An example project would look something like
> 
> ```gradle
> task prepare << {
> println "preparing"
> }
> task longOperation << {
> sleep 50000
> }
> longOperation.dependsOn prepare
> task cleanup << {
> println "clean"
> }
> prepare.finalizedBy cleanup
> cleanup.mustRunAfter longOperation
> 
> ```
> 
> Ideally I’d want ‘cleanup’ to run regardless of the result of ‘longOperation’, but users can get impatient and ctrl-c the task and the entire gradle JVM shuts down (understandably) and then cleanup does not get run, a la:
> 
> ```gradle
> $ ./gradlew -b /tmp/blah.gradle longOperation
> Parallel execution is an incubating feature.
> :prepare
> preparing
> > Building 33% > :longOperation^C
> $
> 
> ```

I have this same problem. Catching SIGTERM should be possible…the entire purpose of a finalizeBy is eg shutting down a test server, so leaving it up when the user wants to just cancel the build trappy behavior!

---

<div class="post-metadata">

**Author:** ![sterling](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sterling/32/5395_2.png) [@sterling](https://discuss.gradle.org/u/sterling)\
**Post date:** [October 5, 2015, 11:51pm UTC](https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c-continued-from-old-forum/12036/2 "2015-10-05T23:51:42Z")

</div>

The long term plan is to use a different signal to ‘cancel’ the build (see the discussion here [Ctrl-c during running build also kills daemon](https://discuss.gradle.org/t/ctrl-c-during-running-build-also-kills-daemon/10158)), so finalizers have a chance to run. Part of the reason we haven’t provided something like this sooner is that it breaks builds that rely on reading from the Console themselves.

We also want to make it so something like a long running test server is more richly modeled (sort of like what’s happening with Play’s local dev server), so Gradle would know how to start/stop it across build invocations.

The short term workaround might be to provide a “stopAllTestServers” task that can be run if a build is canceled mid-test or make the start task smart enough to recover after an incomplete stop.