Applicable to:
- Plesk for Linux
Symptoms
-
Plesk license was not automatically updated on a server:
PLESK_WARN: Warning : You are currently operating within the grace period of your product license. To update your product license, select the Retrieve Keys option on the License Management page.
OR
PLESK_WARN: Your license key has expired. To continue using your Plesk, you must purchase a non-expiring commercial license key.
-
The following message is received by Plesk administrator:
CONFIG_TEXT: Unable to update EXT.12345678.1234: an error occurred while processing your key. You can try to retrieve the key manually in Plesk (Tools & Settings > License Management) or let Plesk try to update it in the next 24 hours. If you do not want to receive this notification any more, remove this key from Plesk.
-
The following errors are found in the
/var/log/plesk/panel.logfile:CONFIG_TEXT: ERR [panel] KeyUpdate Result code: 2 Network failure
ERR [panel] KeyUpdate Result desc: Not valid XML. XML parsing failedOR
CONFIG_TEXT: ERR [panel] KeyUpdate Result code: 2 Network failure
ERR [panel] KeyUpdate Result desc: Not valid XML. no element foundOR
CONFIG_TEXT: TLSv1.2 (OUT), TLS header, Certificate Status (22): > SSL data removed for security reason
* TLSv1.2 (OUT), TLS handshake, Client hello (1): > SSL data removed for security reason
* Unknown SSL protocol error in connection to ka.plesk.com:5224 * Closing connection 0 cURL verbose output:
* Could not resolve host: ka.plesk.com * Closing connection 0
Cause
The corrupted file /etc/sw/keys/registry.xml
OR
The Plesk licensing server (Key Administrator) is overloaded with the same requests.
Resolution
-
Connect to the server via SSH.
-
Remove the
/etc/sw/keys/registry.xmlfile:# rm /etc/sw/keys/registry.xml
-
Log out and log into Plesk again to recreate the removed
/etc/sw/keys/registry.xmlfile. -
Run Daily Maintenance task to update keys on the server:
# /usr/local/psa/admin/bin/php /usr/local/psa/admin/plib/DailyMaintainance/task-script.php UpdateKeys --period=daily
-
If this did not solve the issue, then the cause is that Key Administrator server (the licensing server) gets overloaded when a huge number of cloned virtual machines are trying to reach it for a license update. So if there are a lot of VMs at the same time for the daily maintenance task, then all of VMs will try to contact the licensing server at the same time. In this case, some requests fail due to the Key Administrator server overload, and some get processed successfully.
To solve the issue, change the Daily Maintenance Task execution time on different virtual machines. Due to the fact that a number of tasks are included in DailyMaintenance task, such as backup creation, calculating statistics, that can affect server performance, make sure that it will be started when the server load is minimal.
-
Go to Plesk Management Node > Nodes > 203.0.113.2 and click the Manage Node link.
Note: the affected node has the Unsupported value in the status column
-
Navigate to License Management and click the Retrieve Keys button.
-
Back to the Management Node > Nodes > 203.0.113.2 and click Re-Check link.
Comments
2 comments
The expression as explained in Option 1 seems to be the easiest solution. Why isn't this single line of code included by default? As the solution is already clear, that should be part of the next microupdate!
In addition, the article might let the reader assume that you should shift the task exactly by +/- 1 hour or +/-30 minutes (first sentence in Option 1). But since that basically brings the server to the next/previous time zone, the problem might appear again. Using a random time seems more appropriate.
For option 2: is there a reason why you gave the time range of +/- 30 minutes? Would it hurt if the job starts much earlier/later?
@b_p , solution in Option 1 is not a proper one, the recommended way to change execution time for Daily Maintenance is through task scheduler like cron or anacron.
About random time for DailyMaintenance task there is a feature request https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/18978205 and I assume you have voted for this already.
> For option 2: is there a reason why you gave the time range of +/- 30 minutes? Would it hurt if the job starts much earlier/later?
The main requirement for the start time is to run DailyMaintenance task when the server load is minimal.
Thank you for the input, the article has been updated.
Please sign in to leave a comment.