# Cistub Waiting for Already Running Instance to Finish

> Clear a CapaInstaller client whose job queue is blocked by a hung install script or an installer waiting for input.

Source: https://docs.capaone.com/capainstaller/troubleshooting/cistub-waiting-for-already-running-instance-to-finish/  
Product: CapaInstaller — a separate CapaSystems product; do not apply this page to any other.

## Problem

The agent log on a client repeats the same entry and no packages install:

```text
Cistub : Waiting for already running instance to finish
```

The device still checks in and looks healthy in the console, but its jobs never complete. New
packages queue up behind the stalled one. Restarting the agent service does not help, and the
message returns after a reboot if the same package runs again.

## Cause

`Cistub` is the CapaInstaller Agent Service. It runs one job at a time on a client, so it waits for
the running instance before it starts the next one. The message is the agent behaving correctly —
the problem is the job it is waiting for, which never ends.

A job hangs for one of two reasons:

- **An install script crashed without returning an exit code.** The agent has no result to act on,
  so it keeps waiting for a process that is no longer going anywhere.
- **An installer is waiting for input that nobody can give.** An MSI or EXE started without the
  correct silent parameters shows a dialog. The job runs in system context, where no user sees the
  dialog, so the installer waits indefinitely.

The second cause is the common one. It often appears right after a new package is released, or
after an installer vendor changes its command-line switches between versions.

## Solution

### 1. Find the job that is stuck

Open the client's agent log in `%ProgramFiles%\CapaInstaller\Client\Logs`. Look for the last job
that started and never logged a result. That package is the one blocking the queue.

The per-package logs in `%ProgramFiles%\CapaInstaller\Client\Logs\Advanced` show how far the
package got before it stopped.

### 2. Set the package to Installed

1. In the CapaInstaller Console, open the affected unit and find the failing package in its package
   list.
2. Right-click the package.
3. Select **Installed** to set its status, or **Unlink** to remove the package from the unit.

Set it to **Installed** when the unit should keep the package and you are going to redeploy a
corrected version. **Unlink** it when the unit should not have the package at all.

:::caution[Do this before you end the process]
The agent picks the job up again as soon as it is free. If the package is still pending when you
end the process, the same job starts over and the client blocks again.
:::

### 3. End the hung process

On the client, open Task Manager and find the script process behind the job:

- `wscript.exe` or `cscript.exe` for a VBScript package
- `powershell.exe` for a PowerShell package

Look for the one that started when the job started and is using no CPU. End it.

The script process is the one the agent waits for. If the installer it launched is also still
running, for example `msiexec.exe` or a vendor setup, end that as well.

### 4. Restart the agent

Restart the CapaInstaller Agent Service on the client. The agent then continues with the rest of
the queue.

### 5. Correct the package

Steps 2 to 4 clear one device. The package hangs again the next time it runs, here or elsewhere, so
correct it before you deploy it again.

Test the installer command line manually on a test device before you put it back into production.

- **Run it in system context, not as your own user.** A command that installs correctly in an
  interactive session can still show a dialog under `SYSTEM`. This is the check that catches most
  of these.
- **Verify the silent parameters against the vendor's current documentation.** Confirm the switches
  for the exact version you are deploying.
- **Make the script return an exit code on every path**, including its error handling. A script that
  exits without a code leaves the agent with nothing to act on.

The package now completes and reports a result, and the `Waiting for already running instance to
finish` entries stop.

## Good to know

- **The message on its own is not an error.** Seeing it once while another package installs is
  normal. It matters when it repeats and nothing else progresses.
- **One hung job blocks every later job on that device.** A device that seems to be ignoring all its
  packages is often waiting behind a single bad one.
- **Check whether other devices show the same pattern.** If they do, the package is at fault. If
  only one device is affected, look at that device — see
  [CapaInstaller Agent Stops Working](/capainstaller/troubleshooting/capainstaller-agent-stops-working/).

## Related

- [CapaInstaller Agent Not Installing Packages](/capainstaller/troubleshooting/capainstaller-agent-not-installing-packages/)
- [CapaInstaller log files](/capainstaller/knowledge-base/capainstaller-log-files/)
- [CapaInstaller Processname overview](/capainstaller/appendix/capainstaller-processname-overview/)

<!-- DRAFT NOTE (remove before publishing):
Written from Mikkel's description of the cause (crashed install script with no exit code, or an
MSI/EXE without correct silent parameters waiting for input in the background), plus the documented
facts in the repo: Cistub = CapaInstaller Agent Service (Appendix/CapaInstaller Processname
overview) and the agent log paths (Knowledge Base/CapaInstaller log files).

The recovery procedure (steps 2-4) is Mikkel's, including the ordering: set the package to Installed
BEFORE ending the process, or the job restarts and the client blocks again.

VERIFY BEFORE PUBLISHING:
  - The exact log line. I used "Cistub : Waiting for already running instance to finish" - paste the
    verbatim string from a real agent log, including spacing and any prefix. Fin matches on this.
  - The exact right-click menu item names in step 2. Mikkel described it as "set it to installed or
    unlink the package"; I wrote the entries as **Installed** and **Unlink**. Correct them to match
    the console, and add a screenshot of the context menu if there is one.
  - How the agent should be restarted - the service name to restart, or whether there is a supported
    action in the console or agent UI. Step 4 currently just says "restart the CapaInstaller Agent
    Service on the client".
  - Whether the agent has a job timeout that eventually releases the lock. If it does, say how long
    and drop the impression that the wait is unbounded.
  - Whether "one job at a time per client" is accurate for all agent versions.
-->