From 1d61a9195193fdd934bbe00e3227a147f3c11c45 Mon Sep 17 00:00:00 2001 From: Jim Pelletier Date: Tue, 26 May 2026 13:11:47 +1000 Subject: [PATCH 1/3] Document automatic recovery from stuck PowerShell scripts on Tentacle MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a new section to the "Troubleshooting failed or hanging tasks" page covering the two automatic recoveries that ship with EFT-365 (PowerShell startup detection) and EFT-3295 (cancel-abandon escape hatch). The section sits between the existing "Automatic failure of hanging tasks" subsection (Hung Deployment Detection — a different feature) and the "Antivirus software" subsection (operator-side fix), so the page flows from deployment-level detection, to script-level recovery, to the underlying fix the customer still needs to make. Honest framing throughout: both recoveries are mitigation, the underlying problem is on the target machine, and the abandon path explicitly does not kill the runaway script process. Refs: EFT-365, EFT-3295 Co-Authored-By: Claude Opus 4.7 (1M context) --- ...troubleshooting-failed-or-hanging-tasks.md | 66 ++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md index 216722e9c7..a218128b83 100644 --- a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md +++ b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md @@ -1,7 +1,7 @@ --- layout: src/layouts/Default.astro pubDate: 2023-01-01 -modDate: 2025-01-13 +modDate: 2026-05-26 title: Troubleshooting failed or hanging tasks description: A guide for troubleshooting tasks that fail unexpectedly or are unresponsive navOrder: 8 @@ -63,6 +63,70 @@ In some instances, Octopus will automatically trigger the failure of a task that This is generally indicative of an internal error in Octopus. In Octopus Cloud we actively monitor for these issues, but please reach out to support for further assistance, especially if the problem persists. +### Recovering from stuck PowerShell scripts on Tentacle + +PowerShell scripts on a Tentacle target can sometimes fail to run normally because of interference from antivirus or endpoint-protection software on the target. Without help, this used to leave the target's deployment queue blocked: you'd have to remote into the target and end the process, or restart the Tentacle service, before the next deployment could run. + +Octopus now has two automatic recoveries that keep the queue moving while you investigate the underlying interference. Both are mitigation, not a fix. The underlying problem is on the target machine, and you'll still want to configure your antivirus software ([see the antivirus section below](#anti-virus-software)) so the interference stops happening. + +#### Detecting scripts that never start + +When Tentacle launches `powershell.exe` to run your script, the PowerShell process can sometimes start but never actually begin executing the script body. This typically happens when endpoint-protection software hooks into PowerShell startup and the script content never reaches the runtime. + +If `powershell.exe` doesn't reach the first instruction of your script in 5 minutes, Tentacle marks the task as failed with exit code `-47` and prevents the script body from ever running, even if PowerShell wakes up later. Tentacle records a log line like: + +``` +PowerShell startup detection: PowerShell did not start within 5 minutes for task +``` + +The mutex protecting the target is released as part of normal task cleanup, so the next deployment to that machine can begin straight away. The Tentacle itself stays healthy and doesn't need to be restarted. + +This recovery is supported on Windows Tentacles running `powershell.exe`. Linux `pwsh` is not currently covered. + +#### Releasing the target when cancellation can't take effect + +If you cancel a deployment from the Octopus Web Portal and the cancellation can't take effect on the Tentacle in 2 minutes, Octopus tells the Tentacle to abandon the script and accept new work. This means: + +- The script's underlying process may still be running on the target. Octopus does not kill it. If your script was performing an operation that could leave the target in an inconsistent state (a database migration, a file system change, and so on), inspect the target and clean up manually. +- The Tentacle releases its mutex and immediately accepts the next deployment in the queue. +- The task is marked as Cancelled. + +When abandonment runs, you'll see this in the task log: + +``` +Cancellation hasn't taken effect on Tentacle after 2 minutes. Abandoning the script so this target can accept new deployments. +Tentacle abandoned the script. +``` + +Tentacle's own log will also record: + +``` +Tentacle has abandoned this script. The underlying script process may still be running on this host. +``` + +If your cancellation succeeded cleanly, no abandonment runs and the task is marked Cancelled without these messages. Check your task log to know which path your cancellation took. + +#### Version requirements + +The automatic recoveries described above are available from: + +- Octopus Server `2026.2.5952` or later +- Tentacle `9.1.3801` or later for the script-startup detection +- Tentacle version supporting the cancellation abandon to be confirmed when the work ships + +If either component is on an older version, your deployments use the previous behavior, where a stuck script may require you to remote into the target and end the process manually or restart the Tentacle service. + +#### What to do if automatic recovery fires regularly + +If you see automatic recovery firing on the same target more than occasionally, that target has an environmental problem worth investigating directly. Common causes: + +- Antivirus or endpoint-protection software (CrowdStrike, Rapid7, and similar) hooking into PowerShell startup or holding file locks on the Tentacle's working directories. +- Multiple security agents installed on the same host, contending for the same kernel locks. + +The first step is to configure your antivirus or endpoint-protection software per the [antivirus section below](#anti-virus-software). You can identify how often automatic recovery is firing on a specific target by searching your task logs for the messages above across recent deployments to that target. + +If the recoveries keep firing after exclusions are in place, contact support and include a process dump from the target during the next occurrence. This helps us identify which agent is interfering. + ### Antivirus software {#anti-virus-software} If the task appears to hang after a log message output by the Octopus Server or Tentacle, then in most cases the cause is antivirus or anti-malware software interfering with the task. The first step is to determine if your antivirus software is actually affecting your Tasks, and this can easily be done by removing your antivirus protection and confirming whether the tasks continue to be unresponsive. From 272b91fc1baacd7b116c6e07dcba190eb43b9b3b Mon Sep 17 00:00:00 2001 From: Jim Pelletier Date: Wed, 27 May 2026 15:00:56 +1000 Subject: [PATCH 2/3] Replace embedded section with standalone Tentacle script abandonment page Pivots away from the troubleshooting-embedded approach in the previous commit. The customer-facing product term is Tentacle script abandonment (per the Naming Playbook applied to the Linear ticket title, code, FT name, and Tentacle's own log line). It deserves a standalone page. What changed: - New page at src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md Covers both triggers under one product term: - PowerShell startup detection (EFT-365) - Cancellation timeout (EFT-3295) Explains the underlying cause (target-side AV/EDR interference) with a link to OctopusTentacle#1208 for stack traces and the CrowdStrike + Rapid7 deadlock analysis. Cross-links to the existing antivirus exclusion list rather than duplicating it. - Troubleshooting page: the embedded "Recovering from stuck PowerShell scripts on Tentacle" section is removed and replaced with a short cross-link to the new page. The troubleshooting page stays symptom-led; the new page is product-term-led. Language discipline: no colloquial "stuck", "hung", "hanging", "frozen" anywhere in the customer-facing prose. "script" (not "PowerShell script") for the umbrella behaviour; "PowerShell script" only inside the PowerShell-specific trigger section. Refs: EFT-365, EFT-3295 Co-Authored-By: Claude Opus 4.7 (1M context) --- .../tentacle/tentacle-script-abandonment.md | 98 +++++++++++++++++++ ...troubleshooting-failed-or-hanging-tasks.md | 64 +----------- 2 files changed, 100 insertions(+), 62 deletions(-) create mode 100644 src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md diff --git a/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md b/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md new file mode 100644 index 0000000000..022b89614d --- /dev/null +++ b/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md @@ -0,0 +1,98 @@ +--- +layout: src/layouts/Default.astro +pubDate: 2026-05-27 +modDate: 2026-05-27 +title: Tentacle script abandonment +description: How Octopus Tentacle abandons a deployment script when it can't run normally on the target, what you'll see when it happens, and what to do about the underlying cause. +navOrder: 58 +--- + +Octopus Tentacle can abandon a deployment script when the script can't run normally on the target. Abandonment releases the Tentacle's per-target mutex so the next deployment in the queue can start, even though the script's underlying process may still be running on the target. + +This page covers when abandonment fires, what you'll see when it does, why these failures happen, and what to do about the underlying cause. + +## How abandonment works + +When Tentacle abandons a script: + +- The Tentacle's per-target mutex is released. The next deployment in the queue for that target can start immediately. +- The Tentacle-side runtime locks holding state for the script are dropped. +- The abandonment is logged in the server-side task log and in the Tentacle log. + +What abandonment does **not** do: + +- It does not kill the script's underlying process on the target. If your script was performing an operation that could leave the target in an inconsistent state (a database migration, a file system change, and so on), inspect the target and clean up manually. +- It does not introduce a new task status. Depending on which trigger fired, the task is marked as `Failed` (PowerShell startup detection) or `Cancelled` (cancellation timeout). Check the task log to know which path your task took. + +The Tentacle itself stays healthy after abandoning a script. It doesn't need to be restarted. + +## When abandonment fires + +Tentacle abandons a script in response to one of two triggers. + +### PowerShell startup detection + +Scope: Windows Tentacles running `powershell.exe`. Linux `pwsh` is not currently supported. + +When Tentacle launches `powershell.exe` to run your script, the PowerShell process can sometimes start but never actually begin executing the script body. This typically happens when antivirus or endpoint-protection software hooks into PowerShell startup and the script content never reaches the runtime. + +If `powershell.exe` doesn't reach the first instruction of your script in 5 minutes, Tentacle marks the task as `Failed` with exit code `-47` and prevents the script body from running, even if PowerShell wakes up later. Tentacle records a log line like: + +``` +PowerShell startup detection: PowerShell did not start within 5 minutes for task +``` + +Version requirements: + +- Octopus Server `2026.2.5952` or later +- Tentacle `9.1.3801` or later + +### Cancellation timeout + +Scope: any script on Tentacle. Both Windows and Linux Tentacles. SSH targets and the Kubernetes agent are not in scope. + +If you cancel a deployment from the Octopus Web Portal and the cancellation can't take effect on the Tentacle in 2 minutes, Octopus tells the Tentacle to abandon the script. The task is marked as `Cancelled`. + +The server-side task log records: + +``` +Cancellation hasn't taken effect on Tentacle after 2 minutes. Abandoning the script so this target can accept new deployments. +Tentacle abandoned the script. +``` + +If the script had already completed by the time abandonment was attempted, the second line reads: + +``` +Script had already completed before abandon was needed. +``` + +Tentacle's own log also records: + +``` +Tentacle has abandoned this script. The underlying script process may still be running on this host. +``` + +If your cancellation succeeded cleanly, no abandonment runs and the task is marked `Cancelled` without these messages. Check your task log to know which path your cancellation took. + +Version requirements: + +- Octopus Server version supporting cancellation timeout abandonment (to be confirmed when the work ships) +- Tentacle version that publishes `AbandonScript` on `IScriptServiceV2` (to be confirmed when the work ships) + +## Why these failures happen + +The conditions that lead to abandonment are usually on the target machine, not in Octopus. + +Antivirus and endpoint-protection software (CrowdStrike, Rapid7, and similar) can hook into `powershell.exe` at process startup. When two agents race for the same kernel locks, the process can fail to begin executing the script body. The same agents can hold file locks on the Tentacle's working directories (`Output.log`, `stdout.txt`), blocking the script from making progress or a cancellation from being processed. + +For a worked example with stack traces and a detailed analysis of a CrowdStrike + Rapid7 deadlock on a customer's target, see [OctopusTentacle issue #1208](https://github.com/OctopusDeploy/OctopusTentacle/issues/1208). + +Multiple security agents installed on the same host are the most common pattern. The fix is on the target machine. + +## What to do about it + +Both abandonment triggers are mitigation, not a fix. The underlying problem is on the target machine, and you're best placed to fix it. Three steps, in order: + +1. **Configure your antivirus or endpoint-protection software to exclude Tentacle's working directories.** Specifically `\Tools` and `\Work`. The full exclusion list and additional directories you can include if you're still seeing issues are documented in [Troubleshooting failed or hanging tasks: Antivirus software](/docs/support/troubleshooting-failed-or-hanging-tasks#anti-virus-software). +2. **Keep target-side security tooling updated.** Known interactions between specific CrowdStrike and Rapid7 versions cause the deadlock; vendor updates have addressed similar issues before. +3. **If abandonment fires on the same target more than occasionally,** contact support and include a process dump from the target during the next occurrence. This helps support identify which agent is interfering. You can identify how often abandonment is firing on a specific target by searching your task logs for the messages above across recent deployments to that target. diff --git a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md index a218128b83..a30ee607d2 100644 --- a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md +++ b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md @@ -63,69 +63,9 @@ In some instances, Octopus will automatically trigger the failure of a task that This is generally indicative of an internal error in Octopus. In Octopus Cloud we actively monitor for these issues, but please reach out to support for further assistance, especially if the problem persists. -### Recovering from stuck PowerShell scripts on Tentacle +### Tentacle script abandonment -PowerShell scripts on a Tentacle target can sometimes fail to run normally because of interference from antivirus or endpoint-protection software on the target. Without help, this used to leave the target's deployment queue blocked: you'd have to remote into the target and end the process, or restart the Tentacle service, before the next deployment could run. - -Octopus now has two automatic recoveries that keep the queue moving while you investigate the underlying interference. Both are mitigation, not a fix. The underlying problem is on the target machine, and you'll still want to configure your antivirus software ([see the antivirus section below](#anti-virus-software)) so the interference stops happening. - -#### Detecting scripts that never start - -When Tentacle launches `powershell.exe` to run your script, the PowerShell process can sometimes start but never actually begin executing the script body. This typically happens when endpoint-protection software hooks into PowerShell startup and the script content never reaches the runtime. - -If `powershell.exe` doesn't reach the first instruction of your script in 5 minutes, Tentacle marks the task as failed with exit code `-47` and prevents the script body from ever running, even if PowerShell wakes up later. Tentacle records a log line like: - -``` -PowerShell startup detection: PowerShell did not start within 5 minutes for task -``` - -The mutex protecting the target is released as part of normal task cleanup, so the next deployment to that machine can begin straight away. The Tentacle itself stays healthy and doesn't need to be restarted. - -This recovery is supported on Windows Tentacles running `powershell.exe`. Linux `pwsh` is not currently covered. - -#### Releasing the target when cancellation can't take effect - -If you cancel a deployment from the Octopus Web Portal and the cancellation can't take effect on the Tentacle in 2 minutes, Octopus tells the Tentacle to abandon the script and accept new work. This means: - -- The script's underlying process may still be running on the target. Octopus does not kill it. If your script was performing an operation that could leave the target in an inconsistent state (a database migration, a file system change, and so on), inspect the target and clean up manually. -- The Tentacle releases its mutex and immediately accepts the next deployment in the queue. -- The task is marked as Cancelled. - -When abandonment runs, you'll see this in the task log: - -``` -Cancellation hasn't taken effect on Tentacle after 2 minutes. Abandoning the script so this target can accept new deployments. -Tentacle abandoned the script. -``` - -Tentacle's own log will also record: - -``` -Tentacle has abandoned this script. The underlying script process may still be running on this host. -``` - -If your cancellation succeeded cleanly, no abandonment runs and the task is marked Cancelled without these messages. Check your task log to know which path your cancellation took. - -#### Version requirements - -The automatic recoveries described above are available from: - -- Octopus Server `2026.2.5952` or later -- Tentacle `9.1.3801` or later for the script-startup detection -- Tentacle version supporting the cancellation abandon to be confirmed when the work ships - -If either component is on an older version, your deployments use the previous behavior, where a stuck script may require you to remote into the target and end the process manually or restart the Tentacle service. - -#### What to do if automatic recovery fires regularly - -If you see automatic recovery firing on the same target more than occasionally, that target has an environmental problem worth investigating directly. Common causes: - -- Antivirus or endpoint-protection software (CrowdStrike, Rapid7, and similar) hooking into PowerShell startup or holding file locks on the Tentacle's working directories. -- Multiple security agents installed on the same host, contending for the same kernel locks. - -The first step is to configure your antivirus or endpoint-protection software per the [antivirus section below](#anti-virus-software). You can identify how often automatic recovery is firing on a specific target by searching your task logs for the messages above across recent deployments to that target. - -If the recoveries keep firing after exclusions are in place, contact support and include a process dump from the target during the next occurrence. This helps us identify which agent is interfering. +If your task ends in `Cancelled` or `Failed` and your Tentacle has logged that the script was abandoned, see [Tentacle script abandonment](/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment) for the full explanation and what to do next. ### Antivirus software {#anti-virus-software} From acc6eaf6f6edbb2cc95f4b63f6bb9e12d9db6890 Mon Sep 17 00:00:00 2001 From: Jim Pelletier Date: Wed, 27 May 2026 15:52:52 +1000 Subject: [PATCH 3/3] Address PR feedback from Jim and Luke - Link "per-target mutex" to /docs/administration/managing-infrastructure/run-multiple-processes-on-a-target-simultaneously - Drop "queue" framing: Tentacle picks up the next script it has for that target, not a notion of a queue. - Remove the redundant "runtime locks" bullet (covered by the mutex bullet). - Add `text` language fence to all sample-log code blocks. - PowerShell startup detection scope reworded: PowerShell-only because that's the only context where the failure has been observed (confirmed by @LukeButters in review). - Convert bulleted "Version requirements" blocks to single-sentence prose per existing docs convention. - Drop the "Cancellation hasn't taken effect..." dispatch log line. The current implementation only emits the two outcome lines (`Tentacle abandoned the script` or `Script had already completed before abandon was needed`); the dispatch line was a spec aspiration that isn't in the code yet. - Replace the AIism "The fix is on the target machine." with two concrete sentences naming Octopus's limit and where the fix lives. - Remove the unsupported "vendor updates have addressed similar issues before" claim. Replace with a directive to check the vendor's release notes. - Reword the cross-link section on the troubleshooting page from "Tentacle script abandonment" to "Automatic recovery for hanging tasks" so the heading reads as the solution, not the problem. The canonical product term stays in the link text. Refs: EFT-365, EFT-3295 Co-Authored-By: Claude Opus 4.7 (1M context) --- .../tentacle/tentacle-script-abandonment.md | 34 +++++++------------ ...troubleshooting-failed-or-hanging-tasks.md | 4 +-- 2 files changed, 15 insertions(+), 23 deletions(-) diff --git a/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md b/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md index 022b89614d..1d03e21746 100644 --- a/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md +++ b/src/pages/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment.md @@ -7,7 +7,7 @@ description: How Octopus Tentacle abandons a deployment script when it can't run navOrder: 58 --- -Octopus Tentacle can abandon a deployment script when the script can't run normally on the target. Abandonment releases the Tentacle's per-target mutex so the next deployment in the queue can start, even though the script's underlying process may still be running on the target. +Octopus Tentacle can abandon a deployment script when the script can't run normally on the target. Abandonment releases the Tentacle's [per-target mutex](/docs/administration/managing-infrastructure/run-multiple-processes-on-a-target-simultaneously) so the Tentacle can begin executing the next script it has for that target, even though the abandoned script's underlying process may still be running on the target. This page covers when abandonment fires, what you'll see when it does, why these failures happen, and what to do about the underlying cause. @@ -15,8 +15,7 @@ This page covers when abandonment fires, what you'll see when it does, why these When Tentacle abandons a script: -- The Tentacle's per-target mutex is released. The next deployment in the queue for that target can start immediately. -- The Tentacle-side runtime locks holding state for the script are dropped. +- The Tentacle's [per-target mutex](/docs/administration/managing-infrastructure/run-multiple-processes-on-a-target-simultaneously) is released. The Tentacle can begin executing the next script it has for that target. - The abandonment is logged in the server-side task log and in the Tentacle log. What abandonment does **not** do: @@ -32,20 +31,17 @@ Tentacle abandons a script in response to one of two triggers. ### PowerShell startup detection -Scope: Windows Tentacles running `powershell.exe`. Linux `pwsh` is not currently supported. +We've only observed this class of script-startup failure with PowerShell, so the detection is currently scoped to `powershell.exe` on Windows Tentacles. Bash on Linux Tentacles isn't covered. When Tentacle launches `powershell.exe` to run your script, the PowerShell process can sometimes start but never actually begin executing the script body. This typically happens when antivirus or endpoint-protection software hooks into PowerShell startup and the script content never reaches the runtime. If `powershell.exe` doesn't reach the first instruction of your script in 5 minutes, Tentacle marks the task as `Failed` with exit code `-47` and prevents the script body from running, even if PowerShell wakes up later. Tentacle records a log line like: -``` +```text PowerShell startup detection: PowerShell did not start within 5 minutes for task ``` -Version requirements: - -- Octopus Server `2026.2.5952` or later -- Tentacle `9.1.3801` or later +PowerShell startup detection requires Octopus Server `2026.2.5952` or later and Tentacle `9.1.3801` or later. ### Cancellation timeout @@ -53,31 +49,27 @@ Scope: any script on Tentacle. Both Windows and Linux Tentacles. SSH targets and If you cancel a deployment from the Octopus Web Portal and the cancellation can't take effect on the Tentacle in 2 minutes, Octopus tells the Tentacle to abandon the script. The task is marked as `Cancelled`. -The server-side task log records: +The server-side task log records one of two lines, depending on what Tentacle reports back: -``` -Cancellation hasn't taken effect on Tentacle after 2 minutes. Abandoning the script so this target can accept new deployments. +```text Tentacle abandoned the script. ``` -If the script had already completed by the time abandonment was attempted, the second line reads: +Or, if the script had already completed by the time abandonment was attempted: -``` +```text Script had already completed before abandon was needed. ``` Tentacle's own log also records: -``` +```text Tentacle has abandoned this script. The underlying script process may still be running on this host. ``` If your cancellation succeeded cleanly, no abandonment runs and the task is marked `Cancelled` without these messages. Check your task log to know which path your cancellation took. -Version requirements: - -- Octopus Server version supporting cancellation timeout abandonment (to be confirmed when the work ships) -- Tentacle version that publishes `AbandonScript` on `IScriptServiceV2` (to be confirmed when the work ships) +Cancellation timeout abandonment requires a specific Octopus Server version and Tentacle version. Both are to be confirmed when the work ships. ## Why these failures happen @@ -87,12 +79,12 @@ Antivirus and endpoint-protection software (CrowdStrike, Rapid7, and similar) ca For a worked example with stack traces and a detailed analysis of a CrowdStrike + Rapid7 deadlock on a customer's target, see [OctopusTentacle issue #1208](https://github.com/OctopusDeploy/OctopusTentacle/issues/1208). -Multiple security agents installed on the same host are the most common pattern. The fix is on the target machine. +Multiple security agents installed on the same host are the most common pattern. Octopus can't reach inside that interaction to fix it. The fix lives in your target-side antivirus configuration. ## What to do about it Both abandonment triggers are mitigation, not a fix. The underlying problem is on the target machine, and you're best placed to fix it. Three steps, in order: 1. **Configure your antivirus or endpoint-protection software to exclude Tentacle's working directories.** Specifically `\Tools` and `\Work`. The full exclusion list and additional directories you can include if you're still seeing issues are documented in [Troubleshooting failed or hanging tasks: Antivirus software](/docs/support/troubleshooting-failed-or-hanging-tasks#anti-virus-software). -2. **Keep target-side security tooling updated.** Known interactions between specific CrowdStrike and Rapid7 versions cause the deadlock; vendor updates have addressed similar issues before. +2. **Keep target-side security tooling updated.** Specific versions of certain endpoint-protection agents are known to cause this. Check your vendor's release notes. 3. **If abandonment fires on the same target more than occasionally,** contact support and include a process dump from the target during the next occurrence. This helps support identify which agent is interfering. You can identify how often abandonment is firing on a specific target by searching your task logs for the messages above across recent deployments to that target. diff --git a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md index a30ee607d2..2ca4db4c42 100644 --- a/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md +++ b/src/pages/docs/support/troubleshooting-failed-or-hanging-tasks.md @@ -63,9 +63,9 @@ In some instances, Octopus will automatically trigger the failure of a task that This is generally indicative of an internal error in Octopus. In Octopus Cloud we actively monitor for these issues, but please reach out to support for further assistance, especially if the problem persists. -### Tentacle script abandonment +### Automatic recovery for hanging tasks -If your task ends in `Cancelled` or `Failed` and your Tentacle has logged that the script was abandoned, see [Tentacle script abandonment](/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment) for the full explanation and what to do next. +Octopus Tentacle can automatically recover from many hanging-task scenarios by abandoning the affected script and releasing the per-target mutex. See [Tentacle script abandonment](/docs/infrastructure/deployment-targets/tentacle/tentacle-script-abandonment) for what triggers this, what you'll see in the task log, and what to do about the underlying cause. ### Antivirus software {#anti-virus-software}