Q100177: Unable to communicate with the parent process errors

Follow

SYMPTOMS

When running Katana you may see 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.

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.

 

CAUSE

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 when it's needed it gets launched) 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.
 

RESOLUTION

The 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
 
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.
 
NEXT STEPS

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?
0 out of 0 found this helpful