Skip to main content
Version: 7.7

Troubleshooting

Use the information in this guide to resolve common issues that may occur with your Resolve Actions Pro deployment.

Directory Structure​

Navigating the installation directory of Actions Pro might be necessary when looking for log files, scripts, or commands.

The default installation path is /opt/resolve, but it might be different on your system. Under it, you will find the following directories:

  • bin Contains scripts for:
    • Starting, stopping, restarting, and checking the status of Actions Pro core components.
    • Pre- and post-installation setup.
    • Applying configuration changes (config.sh) made in blueprint.properties. Also contains a symbolic link to blueprint.properties (the main configuration file).
  • elasticsearch
    • config Contains elasticsearch.yml. Do not edit this file unless instructed by your Resolve representative.
    • logs Contains the Elasticsearch logs. The current log file is <Cluster Name>.log. It is rotated daily under names in the <Cluster Name>-<date>.log format.
  • rscontrol, rsmgmt, rsremote, or rssync
    • config Contains config.xml for the respective core component. It stores the applied changes from blueprint.properties.
      • log Contains the core component's log file with a naming convention of <core-component-name>.log (such as rscontrol.log).
  • tomcat
    • logs
      • catalina.out Tomcat Logs like:
        • Start/stop messages
        • Error code 500 (Internal Server error) logs
        • Thread dumps generated by stop.sh -k rsview command
    • conf
      • server.xml Tomcat configuration file responsible for things like port usage, listeners, and ciphers. Do not edit this file unless instructed by your Resolve representative.
  • rabbitmq
    • log/rabbit@<IP address>.log General information and error log for the message queue.
    • config/rabbitmq.config Message queue config file. Do not edit this file unless instructed by your Resolve representative.
    • linux64/rabbitmq/sbin/rabbitmqctl Command-line message queue manager. This file is the starting point to run commands if UI based queries are available.

Finding the PID of a Component​

The process ID (PID) of a Linux process can help you monitor it using the top command or stop it using the kill command. The status.sh script is the easiest way to find the PID of Actions Pro components which are normally identified simply as java by OS tools.

To view the PIDs of all running Actions Pro components, run the following command (substitute your actual installation path for /opt/resolve):

/opt/resolve/bin/status.sh

The output will resemble the following:

Кibana: UP PID: 12717 
LOGSTASH: UP PID: 12855 
RSCONTROL: UP PID: 26768 
RSLOG: UP PID: 12903 
RSMGMT: UP PID: 12534 
RSMQ: UP PID: 11469 
RSREMOTE: UP PID: 21441 
RSSEARCH: UP PID: 12656 
RSVIEW: UP PID: 23407

RSRemote Troubleshooting​

Incorrect Components Shown in RSRemote Administration​

Symptom​

RSRemote Administration shows all components under Resolve Component Status regardless of which RSRemote instance is selected.

Probable Cause​

Actions Pro uses the IP address data to filter components depending on the selected instance. If all your RSRemote instances have LOCATION set to 127.0.0.1 in their Blueprint, then all components will always be shown for all instances.

Possible Resolution​

In the RSRemote Blueprint file, set the LOCALHOST property to the actual IP address of the node instead of 127.0.0.1:

  1. Go to the Blueprint file location:
    • Linux: <actions-pro-home>/bin/config/blueprint-rsremote.properties
    • Windows: <actions-pro-home\rsmgmt\config\blueprint-rsremote.properties
  2. Make a backup of the Blueprint file.
  3. Stop RSRemote:
    • Linux:
      <actions-pro-home>/bin/stop.sh rsremote
    • Windows:
      C:\Program Files\Resolve Systems\bin\stop.bat rsremote
  4. Edit and save blueprint-rsremote.properties.
  5. Reconfigure RSRemote:
    • Linux:
      <actions-pro-home>/bin/config.sh
    • Windows:
      C:\Program Files\Resolve Systems\bin\config.bat
  6. Start RSRemote:
    • Linux:
      <actions-pro-home>/bin/run.sh rsremote
    • Windows:
      C:\Program Files\Resolve Systems\bin\run.bat rsremote

RSRemote Consumes Too Much Resources​

Symptom​

When running multiple RSRemote instances on the same host, RSRemote overconsumes processes.

Probable Cause​

All RSRemote instances are configured to log information to the same location.

Possible Resolution​
  1. Stop the services:
    1. Linux:
      <install dir>/bin/stop.sh all -k
    2. Windows:
      <install-dir>\bin\stop.bat all -k
  2. For all RSRemote instances other than the default instance, do the following:
    1. Open <install-dir>/<instance-dir>/config/log4j2.xml for editing.
      Where instance-dir is the name of the directory where you duplicated the rsremote directory.
    2. Find the following line:
      <RollingFile filePattern="rsremote/log/$${date:yyyy-MM}/rsremote-%d{MM-dd-yyyy}-%i.log.zip" fileName="rsremote/log/rsremote.log" name="RSREMOTE">
    3. Replace it with the following line:
      <RollingFile filePattern="<instance-dir>/log/$${date:yyyy-MM}/rsremote-%d{MM-dd-yyyy}-%i.log.zip" fileName="<instance-dir>/log/rsremote.log" name="<instance-dir>">
      Where instance-dir is the name of the directory where you duplicated the rsremote directory.
    4. Save the file.
  3. Reconfigure the RSRemote deployment:
    <install dir>/bin/config.sh -r
    The -r option forces all local components to reset their GUID values, including the original instance, ensuring that the new RSRemote instance does not share a GUID with the original instance.
  4. Restart the services:
    <install dir>/bin/run.sh all

Performance Troubleshooting​

Automations Execute with a Long Delay or Even Time Out​

Symptom​

Automations fail to start immediately and eventually time out.

Probable Cause​

When too many automations are trying to run at the same time, some of them might be delayed because of the Maximum Execution Events setting, which specifies the maximum number of execution events an instance can take from RSMQ at any one time. If delayed for too long, an automation might reach the system's execution timeout and drop execution.

Possible Resolution​

Consider increasing the value of the Maximum Execution Events setting in the Blueprint file. On each cluster node running RSControl, change the following Blueprint property:

rscontrol.esb.maxexecutionevents