How to Remove Stuck Tasks in Nutanix

Before anything else: if you are not certain what a task is doing, contact Nutanix Support before you touch it. What follows edits the cluster’s task database directly. It is an advanced troubleshooting procedure, not routine housekeeping, and the wrong task aborted at the wrong moment can leave an operation half-finished with no record that it was ever running. Support can tell you in minutes whether a task is genuinely wedged or simply slow.

With that said — stuck tasks are a real and fairly common annoyance. A log collection that never finishes, a snapshot task sitting at kRunning for days, a queue that keeps growing behind one blocked entry. They clutter Prism, and in some cases they block later operations from starting, which is usually what brings people looking for this.

Step 1 — List the active tasks

SSH to any CVM in the cluster and list everything that hasn’t completed:

nutanix@CVM$ ecli task.list include_completed=false

That gives you only the tasks still outstanding — running, queued, or otherwise unfinished:

Task UUID                             Parent Task UUID  Component  Sequence-id  Type                           Status
cde8b3f9-c7da-46a7-7194-bf0628006db2                    Logbay     132          LogCollectionWithDownloadLink  kRunning
f68b291a-c297-45b4-6aaa-bdf26e0e173e                    Logbay     126          LogCollectionWithDownloadLink  kRunning
2be51d3d-8556-4bdf-637b-58bd517ef572                    Logbay     121          LogCollectionWithDownloadLink  kQueued
a0780f21-5150-43c8-6577-86edb1fff3fe                    Logbay     120          LogCollectionWithDownloadLink  kQueued
c424cd94-faac-47e3-7b58-4eb35e505e50                    Logbay     115          LogCollectionWithDownloadLink  kRunning
805b66f9-a88c-446a-7dd8-fa0ae79e42ba                    Logbay     104          LogCollectionWithDownloadLink  kQueued
5f387ed4-d932-4138-8cdd-b59cd7f61683   **               aplos      50128        create_vm_snapshot_intentful   kRunning
926c02dc-d559-4097-6c3a-e6645bbd6eb2                    Logbay     45           LogCollectionWithDownloadLink  kQueued

Read this output properly before you act on it. Four columns matter:

• Component tells you what raised the task. Logbay is log collection — low risk. aplos, ergon, uhura or anything tied to an upgrade is a different matter entirely.
• Type tells you what it’s actually doing. LogCollectionWithDownloadLink is a log bundle. create_vm_snapshot_intentful is a snapshot operation against a VM.
• Status distinguishes kRunning from kQueued. A queued task may simply be waiting behind a running one — clear the blockage and the queue often drains on its own.
• Parent Task UUID matters more than people expect. A task with a parent is a subtask, and aborting it out from under the parent can leave the parent stuck instead. Work on the parent, not the child.

In the example above the task worth investigating is the aplos snapshot task, 5f387ed4-d932-4138-8cdd-b59cd7f61683, sitting at kRunning. Note that the eight Logbay entries with sequence IDs from 45 to 132 are a good illustration of the pattern — one wedged log collection, and everything behind it queuing up.

Step 2 — Confirm the task is genuinely stuck

This is the step people skip, and it’s the one that keeps you out of trouble. A long-running task is not the same as a stuck task. Snapshot operations, replication, disk removal and rebuild activity can all legitimately run for a long time, and aborting one of those mid-flight causes the problem you were trying to avoid.

Before deciding, look at the task in detail:

nutanix@CVM$ ecli task.get <task-uuid>

Check whether the percentage complete is actually moving — run it, wait a few minutes, run it again. A task advancing slowly is working. A task that has not moved in hours, with nothing in the logs to explain it, is a candidate. Also confirm that whatever spawned it has genuinely gone away: a log collection whose requesting session has long since closed is safe to clear; a snapshot task belonging to a protection policy that is still active is not.

Step 3 — Abort the task

Once you’re confident, mark the task aborted using its UUID:

nutanix@CVM$ ergon_update_task --task_uuid='5f387ed4-d932-4138-8cdd-b59cd7f61683' --task_status=aborted

Copy and paste the UUID rather than typing it. And note the flags carefully — those are double hyphens before task_uuid and task_status. If you copy this command from somewhere that has converted them into en-dashes, it will fail with an unhelpful error.

Do one task at a time and re-check between each. Clearing one blocked task frequently releases everything queued behind it, so the list you started with may be shorter than the list you actually need to work through.

Step 4 — Verify

List the active tasks again:

nutanix@CVM$ ecli task.list include_completed=false

On a cluster with nothing else outstanding you’ll get just the header row back:

Task UUID  Parent Task UUID  Component  Sequence-id  Type  Status

That’s the confirmation — the task is no longer among the active set. If the entry is still there, don’t simply run the abort again and hope. Re-read the output: check you used the right UUID, and check whether the task has a parent that’s re-creating it.