Create a ticket

Q100177: Troubleshooting ProcessManager and AssetProcessManager Errors


When running Katana you may see any of the following errors in the Terminal:

ProcessManager: Error communicating with process 0x7f8b04001410 (attempt 1 of 5).
ProcessManager: Error verifying alive status of process 0x7f8b04001410.
ProcessManager: Error verifying 'getwork' status of process 0x7f8b04001410.
ProcessManager: Failed to spawn as many processes as requested.
ProcessManager: Process acquisition failed.
AssetProcessManager: Error acquiring interpreter to run command 'isFileSequence' on 'FileSeq'.
AssetProcessManager: Error communicating with sub-process.
AttributeScriptInterpreter: unable to communicate with the parent process

You may also find error locations in your scene graph with one of the following messages:

Error spawning Python interpreter
Error executing AttributeScript: The interpreter process could not be reached.

These errors indicate a failed communication between child Python processes spawned to handle AttributeScripts and Python Asset Plug-ins and Katana, and may lead to a crash.



Katana 2.0 and later run AttributeScripts and Python Asset Plug-ins in a separate subprocess. Katana's internal Process Manager maintains these active processes and allocates new ones when requested.  Occasionally these processes may take longer than expected to start up (for example due to heavy network load) and you may see "unable to communicate with parent process" error messages printed to the terminal.

Generally, at any given time there are up to two Python subprocesses launched by Katana's ProcessManager - one dedicated to processing AttributeScripts and one to processing Python Asset Plug-ins. Each process is launched lazily (only launched when it's needed) and if your scene uses no Python Asset Plug-ins or contains no AttributeScript nodes there should be no ProcessManager subprocesses spawned or errors shown.
However, if a process is launched then it will exist for the duration of the Katana UI/render session and may produce such errors.


  • If you are seeing these errors with custom plug-ins, please ensure that they are placed in the right folders within KATANA_RESOURCES. For example, errors like these can appear if an asset plugin is mistakenly placed in the "Plugins" folder instead of the "AssetPlugins" folder.
The other method to workaround this problem depends on the version of Katana you are running:
KATANA 2.0 and 2.1
In Katana 2.0 and 2.1 these processes will be killed by the ProcessManager if they become unresponsive.
However, we are aware of issues where Katana will not wait long enough after spawning the child process for it to reply, and declares the child process dead prematurely.
While still using AttributeScript nodes or Python Asset Plug-ins that spawn Python processes, you can modify this behaviour by setting the following two environment variables, depending on your workflow requirements:

- KATANA_IPC_MAX_SPAWN_ATTEMPTS -- The maximum number of times the ProcessManager should attempt to spawn a process before reporting unable to do so. The default value is 5.

- KATANA_IPC_MAX_VERIFY_ATTEMPTS -- The maximum number of times the ProcessManager should attempt to verify if a process is alive and ready to accept work. The default value is 101.

- The ProcessManager will attempt to verify if a process is alive and ready to accept work for each KATANA_IPC_MAX_SPAWN_ATTEMPTS time. 

- Only if all KATANA_IPC_MAX_VERIFY_ATTEMPTS fail (for a given spawn attempt) will you get the "Error communicating with process" message logged to console.

We recommend setting the environment variable KATANA_IPC_MAX_VERIFY_ATTEMPTS to 1000. This effectively forces Katana to keep trying to communicate with the newly-created child process for up to one minute which should be sufficient. You may notice an increased delay at the start of each render while Katana attempts to establish communication with its child processes, but this should be a one-off event.

Katana 2.5 contains general improvements to the reliability of Python Asset Plug-ins and AttributeScripts. In particular:
  • Katana no longer terminates a sub-process responsible for running AttributeScripts or Python Asset Plug-ins if it takes longer than 5s to launch. 
  • Katana no longer hangs if one of these sub-processes crashes.
The environment variable KATANA_IPC_MAX_VERIFY_ATTEMPTS, which indirectly affected how long Katana waited for a sub-process to reply, has been deprecated in Katana 2.5.
There is now a new environment variable that controls the length of time Katana will wait for a sub-process to launch (which by default is one minute): KATANA_IPC_SPAWN_TIMEOUT_S
This takes a value in seconds and accepts a minimum of 5 seconds.
We recommend using this version to take advantage of the improvements made to AttributeScripts and Python Asset Plug-ins performance.
If you encounter these errors then please try setting the appropriated environment variables for the version of Katana you are running. If you still encounter problems then please open a Support ticket and let us know the issue you are encountering and the troubleshooting steps you have taken so far. 
For more information on how to open a Support ticket, please refer to the 'Using the Support Portal' article.
Was this article helpful?

We're sorry to hear that

Please tell us why
0 out of 0 found this helpful