Skip to main content
Version: 7.7

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