ActiveGate 1.335 not reporting "sqlPostgres" capability after disk expansion

[juanvelezH]

When configuring an extension in Dynatrace, it is generating an error for me.

• ActiveGate Version: 1.335.20 (Linux)

• Target: PostgreSQL (Azure PaaS) extension.

• I'm unable to activate the PostgreSQL extension. The UI shows the following error:

  "Failed to assign monitoring configuration to ActiveGate. Reason: The monitoring configuration requires ActiveGate version 1.318.0 or later that supports data source sqlPostgres and belongs to group 'default'"

  Checking the ActiveGate deployment status, the "sqlPostgres" and "python" capabilities are missing from the list, even though the AG version is higher than required.

  Actions already taken:

  1. Disk Space: Initially, /opt was full (559MB free). We expanded the partition to 3GB (currently 2.6GB free).

  2. Permissions: Verified and reapplied chown -R dtuserag:dtuserag and chmod 755 to /var/lib/dynatrace/remotepluginmodule.

  3. Service Restart: Performed systemctl restart dynatracegateway.

  4. Clean Start: Attempted to clear remotepluginmodule/agent/runtime and libs folders to force a fresh plugin download, but the folders were empty, suggesting the EEC never initialized.

  5. Config: Verified custom.properties to ensure the Extension Execution Controller (EEC) is enabled.

  Current Status: The service is running, but the remotepluginmodule (EEC) process doesn't seem to be registering the data sources in the cluster. No "sqlPostgres" capability is visible in the UI.

  Question: Is there any internal flag or specific log I should check to see why the EEC is refusing to download the Python/Postgres modules now that space is available?

[AntonPineiro]

Hi,

ActiveGate logs will provide you more details. Have you create a specific group instead of using default one?

Best regards

[juanvelezH]

"Hi, thanks for the suggestion.

Regarding the ActiveGate Group, I am still using the 'default' group.

However, after deep diving into the dynatracegateway.0.0.log, we found the root cause of why the RemotePluginModule (EEC) was not starting despite having enough disk space (2.6GB free) and being enabled in custom.properties.

The logs showed the following error: WARNING [Autoupdate] RemotePluginModule auto update check finished with error: Autoupdate: Installer file download abandoned: installer file already exists.

It seems that during the previous "disk full" event, a corrupt or incomplete installer was left in the temporary folders, blocking any new update or installation attempts.

We have just performed the following 'Hard Reset' to unblock it:

1. Stopped the ActiveGate service.

2. Cleared /var/lib/dynatrace/gateway/temp/ to remove the corrupt installer.

3. Deleted extension_execution_controller.json to reset the module state.

4. Cleared the remotepluginmodule/agent/runtime/ and libs/ folders.

5. Restarted the service.

We are currently waiting for the ActiveGate to perform a clean download of the RemotePluginModule. If the remotepluginmodule process successfully starts, the 'sqlPostgres' capability should finally appear.

I will update this thread as soon as the process is visible in the OS."

[juanvelezH]

"Hi, thanks for the suggestion.

Regarding the ActiveGate Group, I am still using the 'default' group.

However, after deep diving into the dynatracegateway.0.0.log, we found the root cause of why the RemotePluginModule (EEC) was not starting despite having enough disk space (2.6GB free) and being enabled in custom.properties.

The logs showed the following error: WARNING [Autoupdate] RemotePluginModule auto update check finished with error: Autoupdate: Installer file download abandoned: installer file already exists.

It seems that during the previous "disk full" event, a corrupt or incomplete installer was left in the temporary folders, blocking any new update or installation attempts.

We have just performed the following 'Hard Reset' to unblock it:

1. Stopped the ActiveGate service.

2. Cleared /var/lib/dynatrace/gateway/temp/ to remove the corrupt installer.

3. Deleted extension_execution_controller.json to reset the module state.

4. Cleared the remotepluginmodule/agent/runtime/ and libs/ folders.

5. Restarted the service.

We are currently waiting for the ActiveGate to perform a clean download of the RemotePluginModule. If the remotepluginmodule process successfully starts, the 'sqlPostgres' capability should finally appear.

I will update this thread as soon as the process is visible in the OS."

[AntonPineiro · Accepted solution]

Hi,

Root cause is clear. When it is back, I would suggest you having a dedicated group for extensions instead of default one.

Best regards

[juanvelezH]

Thank you for the advice regarding dedicated ActiveGate groups; it is definitely a best practice we will consider for future optimizations.

However, I would like to point out that we have other tenants with the exact same 'default' group configuration working perfectly for similar extensions. This leads us to believe that the group selection is not the root cause of the current installation failure.

Right now, our main blocker is the installer loop (installer file already exists) preventing the RemotePluginModule from starting at all. We are focused on solving this technical state first to get the capabilities back online. Once the module is running, we will evaluate migrating to a dedicated group as suggested.

I will keep you posted on the results of the manual purge we are performing