Thread Starter
user
(@dnshost)
This just happened on yet a second, long-running and high-traffic website. Exactly the same issue as yesterday’s. I’ve removed your problematic plugin permanently from all installations. This is not the first time I’ve had issues with this plugin bleeding the server of its resources. The last was when you changed the DB tables.
If anyone else has this problem, delete your plugins/wp-security-audit-log folder (as you probably will be unable to access WordPress’ admin interface to remove the plugin). Then either restart your MySQL server, entire web server, or manually log into MySQL from the command line (mysql -u [user] -p) and issue the command “show processlist;”. Find all of the hung processes that are yours that resemble the screenshot at http://i58.tinypic.com/iz1fnt.jpg — find the process ID (first column) and issue the command “kill [id]” for each one that is stuck.
Hi dnshost,
First of all I am sorry to hear you are having problems with our plugin. I can assure you that this issue is not common at all, it might be related to your specific setup.
We have thousands of installs, some of which run on WordPress multisite with hundreds of websites yet the plugin works fine.
We are more than willing to help you troubleshoot this issue therefore can you please contact us on plugins@wpwhitesecurity.com?
Looking forward to hearing from you.
Hi dnshost,
We just released a new version of our plugin which has a more robust database structure thus should be performing much better when monitoring WordPress sites.
We also fixed some database issues hence I would recommend you to try the latest version of the plugin.
Keep us posted 🙂
Thread Starter
user
(@dnshost)
hi dnshost,
Yes we noticed that there is another user that has the problem, thanks for pointing it out.
In the meantime I can confirm we’ve received your email. Thank you for the detailed feedback. We are looking into the issue and will keep you posted with the progress.
In the meantime should you have any further queries, do not hesitate to get in touch.
Thread Starter
user
(@dnshost)
Hi dnshost,
Yes we have seen the problem with Friedi, there is no need for you to point it out to us. I must say I am really disappointed with your attitude.
You complain about a problem with the plugin, we have asked for feedback and yet you never gave us any feedback to help us solve the issue. If you have a technical background I am sure that you understand that a simple “My plugin is not working” will not help us solve the issue.
If you want us to help you solve the issue please give us more details about your scenario, for example what version of the plugin are you using? Is it an upgrade or a new install etc? As explained in my first message it would be easier if you contact us via email since it is better not to disclose such details in public forums.
Hence if you want us to help you, please get in touch with us, else we cannot do much.
Excuse me Robert, but I most certainly did provide you with an email full of information that might help you discover where the problem is, including server stats, time of occurrences, and plugins installed on 2 installations that ran your plugin and experienced a problem. Furthermore, my initial post provided the stuck MySQL queries that were bogging down my server, causing other websites housed on the same server to come to a grinding halt. I merely pointed out Friedi’s review as an example that it was not an isolated incident.
And you have the audacity to berate me for my “attitude” after you insinuating that this was by my own fault…
We have thousands of installs, some of which run on WordPress multisite with hundreds of websites yet the plugin works fine.
Nice of you to quickly backtrack and delete your message after realizing that I did indeed send you technical information per request.
Thank you for your email.
We are looking into the issue right now and will keep you posted. WE will get in touch if we need more details.
That’s fine, no apology needed. I think we’re done here. For the sake of others reporting bugs, I certainly hope how you and WP White Security have handled this matter is not standard practice.
Yep, I have the same problem and yes I was not able to access the account to disable. I had to delete the files to deactivate the plugin.
HI dnshost,
Unfortunately your first support request on this thread was not cooperative at all; rather than asking for help you simply blamed our “problematic plugin” and explained to users how to remove the plugin etc, hence we started off on the wrong foot.
We asked you to send an email yet before sending any emails it seems you were more interested in pointing out that there are other users with the issue rather than cooperating with us and help us solve the issue for users, who like you might be encountering the same issue.
As explained we did receive your email at a later stage and we did reply to you asking for more information. If you would like to continue helping us, we would be more than happy. If you do not want to, we are very sorry.
Having said that we are humans and all of our work is available for free, we spend countless amount of hours developing and testing so people like you can benefit from our plugin, and we do mistakes as well.
Therefore please appreciate the fact that we do get offended when someone seems to be trying hard to spread the word around that our plugin is problematic rather than being cooperative, since it seemed so in the beginning. It was a misunderstanding and we would like to apologize for it.
Hi Robert. I need to tell that the information from dnshost did help me prevent another overload. My problem was that as soon my account had been reactivated the plugin produced an overload again so that I wasn’t able to login to my WP.
Anyway the deletion of the plugin files was the only way to switch the plugin off.
HI Friedi,
In all fairness by deactivating the plugin does not help solve the issue, as in it solves your issue but we won’t be able to identify the problem.
In all fairness dnshost did report back to us via email and gave us more information. In the meantime from the query you posted we might be able to decipher something. Would it be possible to send us an SQL export of the plugin tables from your WordPress database? The tables are:
wp_wsal_metadata
wp_wsal_occurrences
From these tables we can see which alerts were being generated when the load was increasing and help us solve the issue. You can send them to us via email to plugins@wpwhitesecurity.com.
Looking forward to hearing from you.
Hi all,
We finally identified the issue and fixed it. We just released version 1.2.4 of WP Security Audit Log.
Please upgrade the plugin to solve the problem you reported above. Would appreciate if you get back to us and give us an update.
Looking forward to hearing from you and thanks for supporting us!
Hi,
To speak frankly I am not the specialist of those things and I dont have direct access in real time to the server log.
So, the problem I have is, if I check out this version and the problem isn’t really solved my DB will be locked again automatically for 4 hours.
Regards
Friedi
Hi Friedi,
I see your point and I understand your position. Though I can now guarantee you 100% that the issue won’t happen. You posted the actual SQL query that was causing the issue and now we are not using it anymore. We are using WordPress’ own cache, so this problem will not happen.
If you want drop us an email on plugins@wpwhitesecurity.com and we can discuss this further, though again I can guarantee you that this will not happen again 🙂
I activated the olugin after an update.
Hoping and praying ^^
Keep us posted 🙂 I am more than confident that the issue won’t hit you again. If all goes well we would still like to be updated.
