System Settings / Servers / Remote Usage Stats

[nmdpa3]

After upgrade to 8.2.0, the remote useage stats and load averages on the servers page is defaulting to the values of the first server in the list for every server.

If you refresh them individualy, or with the refresh all button, it gets updated to the correct value, however leaving then returning to the page results in the same behavior.

 

 

[WHMCS John]

Hi @nmdpa3,

This data is updated on an hourly basis by the ServerUsageCount and ServerRemoteMetaData automation tasks.

Please ensure that your cron job is triggering the cron.php file on a regular basis, we recommend 5 minute intervals. The Automation Status page should flag any issues with the timing: https://help.whmcs.com/m/automation/l/678170-verify-whether-your-system-cron-is-completing-successfully

If that's all fine, please enable the Module Debug Log to examine the data being returned by the server each hour: https://help.whmcs.com/m/troubleshooting/l/679715-troubleshooting-module-command-errors

 

[nmdpa3]

Not really seeing an issue which is puzzling.  Cron is running every 5 minutes.  This was not a problem prior to the upgrade.  As a side note, this is the 2nd API issue we've seen with Plesk.  A fix was provided to us this past weekend to correct the first, which was related to Plesk module not provisioning new accounts due to API call issues introduced with the upgrade.  This stats update issue is not a critical issue for us at the moment, since refreshing the stats manually with the refresh button works, but something is definitely different after the upgrade to 8.2 -- since it was working prior to that and nothing else was changed.  If I get a chance, I will enable debuging, but not a path I prefer to take on a production system.

Edited June 29, 2021 by nmdpa3

[websavers]

We're seeing the same issue here.

Furthermore it appears to interrupt the ability to update hosting usage stats.

When I go to the Disk Usage Summary report and click "Update Now" at the bottom, the module log shows plesk_usageupdate on all servers result in something like this (I've trimmed it down and replaced the actual domains):

Array
(
    [@attributes] => Array
        (
            [version] => 1.6.4.0
        )

    [webspace] => SimpleXMLElement Object
        (
            [get] => SimpleXMLElement Object
                (
                    [result] => Array
                        (
                            [0] => SimpleXMLElement Object
                                (
                                    [status] => error
                                    [errcode] => 1013
                                    [errtext] => domain does not exist
                                    [filter-id] => domain1
                                )

                            [1] => SimpleXMLElement Object
                                (
                                    [status] => error
                                    [errcode] => 1013
                                    [errtext] => domain does not exist
                                    [filter-id] => domain2
                                )

                            [2] => SimpleXMLElement Object
                                (
                                    [status] => error
                                    [errcode] => 1013
                                    [errtext] => domain does not exist
                                    [filter-id] => domain3
                                )

                        )

                )

        )

)

Prior to the 8.2 update, usage stats updates were working fine. All resource usages show last update was roughly a week ago.

It looks like it's attempting to load stats from all servers by sending each API query (for all the servers) to just the first server. It successfully obtains usage stats from our first server in the list for both resellers and customer objects in Plesk. But then it sends the API query for subsequent servers through to that first servers as well, resulting in the 'domain does not exist' errors -- which is correct as WHMCS is querying the wrong server.

We've already applied these hotfixes:
-  CORE-16812 - Plesk Login to Panel SSO IP
- CORE-16765 - TypeError provisioning Plesk services
- CORE-16844 - Add zero price recurring products to cart

Which apparently don't help with this particular issue.

More details:

• Our cron is set to run every 10 minutes and shows successful on the Automation Status page
• It even says:  Server Usage Stats -- Task completed successfully. (which can't be true, so whatever it's using to judge that seems to be failing as well).
• Activity log shows the following during daily cron: Server Usage Update Failed: Error code: 1013. Error message: Reseller does not exist - Server ID: XX (this is because of the reasoning above -- it's looking for a reseller on the wrong server).

I think it's pretty clear that something in the servers loop is preventing iteration and only returning the first server in the list.

Edited July 7, 2021 by websavers
Add more details at bottom

[websavers]

On 7/7/2021 at 10:01 AM, websavers said:

I think it's pretty clear that something in the servers loop is preventing iteration and only returning the first server in the list.

Having worked with the Plesk API and PHP SDK before, I suppose an alternative explanation could be that the session created by the connection to the first server isn't being invalidated and is being passed on to the next connection attempt, despite the difference in connection info (ie: new server hostname, username, password)

[websavers]

Confirmed as Case #MODULE-7660 -- WHMCS devs are working on it, no timeline to repair.

[mikesoper]

I also have the similar case. Thanks for smart case and solution.

[WHMCS ChrisD]

Hello Everyone,

I am pleased to advise that a Hotfix is now available for this issue and can be obtained via the below link.

Please unzip this attachment and place the files in your WHMCS directory. If asked to overwrite any files please do so.

This hotfix applies to WHMCS 8.2.1 only