Articles in this section

See more

License was not automatically updated on Plesk: KeyUpdate Result code: 2 Network failure

Avatar
Alexey Lapshin
Updated
Follow

 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.log file:

    CONFIG_TEXT: ERR [panel] KeyUpdate Result code: 2 Network failure
    ERR [panel] KeyUpdate Result desc: Not valid XML. XML parsing failed

    OR

    CONFIG_TEXT: ERR [panel] KeyUpdate Result code: 2 Network failure
    ERR [panel] KeyUpdate Result desc: Not valid XML. no element found

    OR

    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

Plesk without Multi Server

  1. Connect to the server via SSH.

  2. Remove the /etc/sw/keys/registry.xml file:

    # rm /etc/sw/keys/registry.xml

  3. Log out and log into Plesk again to recreate the removed /etc/sw/keys/registry.xml file.

  4. 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

  5. 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.

Plesk Multi Server

  1. Log into Plesk Management Node.

  2. 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

  3. Navigate to License Management and click the Retrieve Keys button.

  4. Back to the Management Node > Nodes > 203.0.113.2 and click Re-Check link.

Comments

2 comments

Sort by Date Votes
  • Avatar
    b_p

    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?

    0
    Comment actions Permalink
  • Avatar
    Nikolay Zhmuk

    @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.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request

Related articles