Changelog Description

Store launched process information in a local database and add process monitoring/output manager.

Additional review information

When process is run, this will store information about it in local sqlite3 database that can be later on used by other parts of AYON. It also passes temporary file as stdout and stderr handle, storing its path along the process information.

All this information can be used to read out what the launched process is outputting in situations where it doesn't open its own console. For this Process Monitoring tool is added:

This tool can be run using Process Monitor item in Tray menu.

What it does:

• periodically refresh process list from database
• checks if process is still running
• can open file with process output and reload it periodically
• you can clean output files for any inactive process
• it colorize output if it contains ANSI sequences
• it can handle wrapping shell scripts as executables (scripts that will at the end launch the "real" executable)

Further enhancements:

• connect to message broker and send logs there (https://github.com/ynput/ayon-rabbitmq)

Shell scripts and passing of PID back to AYON

When launching applications through shell scripts on Linux, the process ID returned by the app_launcher (mid-process) corresponds to the shell process, not the actual application process that the shell script launches.

Architecture Overview

• AYON Applications Manager (manager.py) creates launch contexts and manages application processes
• App Launcher (app_launcher.py/app_launcher.cpp in ayon-launcher) is the mid-process that handles detached process launching on Linux
• Shell Scripts are often used as executables that set up environment and launch actual applications

Solution

The solution implements a PID file convention that allows shell scripts to communicate the actual application PID back to AYON through the app_launcher mid-process.

How it Works

1. PID File Creation: The AYON manager creates a temporary PID file and provides its path to the app_launcher via JSON data
2. Environment Variable: The app_launcher passes the PID file path to shell scripts via AYON_PID_FILE environment variable
3. Shell Script Responsibility: Shell scripts can write the actual application PID to this file after launching the application
4. PID Discovery: The app_launcher waits briefly and checks for an updated PID in the file, using it if found

Integration Requirements

For shell scripts to take advantage of this feature:

1. Check if $AYON_PID_FILE environment variable exists
2. Launch your application in the background using &
3. Capture the PID using $! (bash) or equivalent
4. Write the PID to the file specified by $AYON_PID_FILE

Bash Example

#!/bin/bash

# Launch the actual application in background
/path/to/actual/application "$@" &

# Get the PID of the actual application
APP_PID=$!

# Write the PID to the AYON PID file if available
if [ -n "$AYON_PID_FILE" ]; then
    echo "$APP_PID" > "$AYON_PID_FILE"
fi

# Wait for the application to finish (optional)
wait $APP_PID

Testing notes:

You should be able to run any DCC as usual and see its output in Process Manager. It works on Linux and macos. Try to wrap and execute some application in shell script as shown in the example above - Process Manager should still pick the correct process id and monitor the process. Removing of selected item/All inactive items should work too. If you use ANSI sequences to colorize your shell script, you should see that also in the output (it supports even bold, underline, ... styles).