# Killing Gateway Scripts Via Scripting

**URL:** <https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674>\
**Category:** Ignition\
**Tags:** ignition81, scripting\
**Created:** [October 6, 2021, 7:54pm UTC](https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674 "2021-10-06T19:54:28Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![bzink1](https://avatars.discourse-cdn.com/v4/letter/b/bc79bd/32.png) [@bzink1](https://forum.inductiveautomation.com/u/bzink1)\
**Post date:** [October 6, 2021, 7:54pm UTC](https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674/1 "2021-10-06T19:54:29Z")

</div>

We have some scripts that do some heavy lifting in regards to pulling historical tag data out of our Canary Historian and parsing items together. There is an issue with having a bunch of concurrent users and requesting a large amount of data that cause some scripts to lock up. We’re working separately on that issue, but as a fail-safe, has anyone found a way to access/kill gateway scoped scripts via scripting?

We have some tags with alarming that trigger if the CPU for the gateway exceeds 80% for some period of time. Ideally, if that triggers, we could run a script that kills any currently running scripts that have been running for more than 15 minutes or something along those lines instead of manually having to kill them every time. Has anyone found a way to access that information and kill a script programmatically as opposed to manually going through and clicking the buttons to kill it?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [October 6, 2021, 7:58pm UTC](https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674/2 "2021-10-06T19:58:38Z")

</div>

> [@Thread Descriptions in Diagnostics Menu](https://forum.inductiveautomation.com/t/thread-descriptions-in-diagnostics-menu/36264/2):
>
> For the first request, changes are coming soon - possibly as soon as 8.0.15. Right now, there’s no way to set that description, but there will just be a description keyword argument to provide on your system.util.invokeAsynchronous calls. For the latter: from com.inductiveautomation.ignition.common.script import ScriptManager for script in ScriptManager.executingScripts(): if script.description == "My Async Thread": ScriptManager.interrupt(script.threadId)

In addition to the `threadId`, each element in the `executingScripts()` list will have a `startTime` long timestamp.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 6, 2021, 8:44pm UTC](https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674/3 "2021-10-06T20:44:54Z")

</div>

You might also consider restructuring to use a work queue to throttle Canary access. I would use a custom thread pool, but there are numerous ways to approach the problem.

Hmm. Maybe I should add a reference implementation to `later.py`.

---

<div class="post-metadata">

**Author:** ![bzink1](https://avatars.discourse-cdn.com/v4/letter/b/bc79bd/32.png) [@bzink1](https://forum.inductiveautomation.com/u/bzink1)\
**Post date:** [October 6, 2021, 8:53pm UTC](https://forum.inductiveautomation.com/t/killing-gateway-scripts-via-scripting/51674/4 "2021-10-06T20:53:36Z")

</div>

This is great, it will at least give us a temporary holdover until we can solve the root issue, thanks!