• I run CloudLinux 8 / CloudLinux 9 servers with cPanel, MySQL or MariaDB, and alt-php, some with MySQL Governor and some without.

    On any server where BLC was autoupdated on August 5th to version 2.4.9, I’m finding that MySQL/MariaDB resources are being exhausted when a BLC process locks a table and then some other BLC process(es) spin of a ton of ALTER statements. Because the table is locked, the ALTER statements cannot be processed. This builds up connections and outstanding statements in MySQL / MariaDB that cannot be processed. This eventually leads to MySQL / MariaDB exhaustion.

    Basically any of the 25 or so sites that updated to 2.4.9 on August 5th can cause this problem to occur, effectively causing a denial of service to MySQL and rendering all the sites on the server unable to connect to MySQL / MariaDB.

    I do not have information from “mysqladmin processlist’ or full process list to show you since I had to go through and disable the plugin on every user’s site that updated to ensure that it doesn’t cause a DoS on my servers. My customer’s website availability is #1, and I cannot / will not attempt to provides logs when it happens on production servers. I remediate the problem and then report the problem.

    I just want somebody to understand that in a shared hosting environment where there are one or 10s or 100s of sites running 2.4.9 version of the BLC plugin, it is entirely possible for just one site to exhaust MySQL/MariaDB resources. I had to deal with 6 outages caused by BLC 2.4.9 on six separate sites yesterday until I was able to determine specifically what was going wrong and disable those plugins.

Viewing 3 replies - 1 through 3 (of 3 total)
  • I am seeing the same issue as of the auto-update this morning. Had to remove the plugin from a number of websites as it was causing locks in the database, bring all the websites down. No longer trust this plugin so will be removing it from all websites and looking for an alternative.

    Our server admin said:

    “Hello,

    The issue is it runs alter table statements to update from version 17 to 18 and sets a md5 on url_hash() but it has no locking so it fires on every request and never completes. Really poor code not designed or tested against scale (and this isn’t even a very big install) and upgrade_database() fails before writing the updated version so it fires again . This is the function that keeps doing the alters on every request make_schema_current()

    Writing a transient lock so it only fires this on one request is the correct behaviour for these type of updates otherwise you simply flood the database when it deals with larger data. Then this is basically this what I gathered from looking is the root bug

    It runs

    ALTER TABLE wp_blc_links ADD UNIQUE KEY url_hash (url_hash)

    Gets an error

    ERROR 1062 Duplicate entry ” (10,271 collisions)

    The delta() function records the failure, have_errors = true, make_schema_current() returns false, version stays 17, next request repeats so it never completes the upgrade and just floods the database on every request with the same attempt to upgrade.”

    We has to disable the plugin too.

    Plugin Support Williams – WPMU DEV Support

    (@wpmudevsupport3)

    Hi @ohioguy @nirajshah-1 @ll09 ,

    I’m sorry to see that you’re facing this issue.

    It was reported to the Broken Link Checker team, and they released an update as soon as possible, which is version 2.4.10.

    Could you please update the Broken Link Checker to this version and let us know if it makes a difference?

    If you still have the issue after this, please clear all caches on your site(including Object Caching if there is) and let us know how it goes.

    I hope to hear back from you soon.
    Best Regards,
    Williams Valerio

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.