User Login > Failed Login Records crashes apache

When we navigate to User Login > Failed Login Records our apache web server crashes.

Can you ask your host provider to check the server error logs to see if there might be logs related to the server crashing when you are trying to view that page?

Are you hiding your login page using one of the brute force features?

I did a bunch of sifting through our logs, didn’t find anything useful.

We did, however, find our database had ~375K records in the failed logins table. We found that truncating the wp_aiowps_failed_logins table resolved this issue.

Thanks for that info.
We will add an automatic cron cleanup process for the failed logins table to ensure that it doesn’t get too big.

Dear wpsolutions,

I also encountered a problem regarding this.
I updated a website and there was something wrong, so I wanted to restore a backup. Unfortunately the database backup was over 450 MB, consisting of more than 4.500.000 lines. Almost 4.300.000 lines were from the wp_aiowps_failed_logins table. I had to remove them manually and had a lot of work.
Is there an option to automatically limit the database entries or log only x days for example? Or to completele disable this database logging?

Kind regards,
Dennis

https://www.ads-software.com/plugins/all-in-one-wp-security-and-firewall/

I’m having a similar problem with a number of failed login attempt messages being generated and have completed the steps mentioned previously in this thread but they still keep coming.

We renamed the login page several times and now, whenever the plugin is active the URL we made it does not work…meaning we need to disable the entire plugin to be able to login to the dashboard. Painful.

The https://sitename.com/cms/xmlrpc.php prompts a 404 regardless of if the plugin is active, disabled or deleted.

The database tables have been cleared. There wasn’t a large number like other posts.

I’ve looked for a way to be able to manually change the login page via the plugin so when it’s active we can see what’s being set but there doesn’t seem to be any information available for that.

When we enter the correct login URL with the plugin active, the only minor difference we can see is the page title being set to
November 30, -0001 Archives

Can you please review this after the holidays?

Thanks
Ian

hi there,

i’m also having a similar problem, on one of our websites which didn’t have login lockdown activated, there is 2.8 million rows in the aiowps_failed_logins section of the database.

I have tried to empty the table in phpmyadmin, which times out. I also tried to get in via the /wp-admin/admin.php?page=aiowpsec_userlogin section, and clicking on failed records, but it’s just not loading.

it’s making backups of the site very difficult, so any suggestions/improvements to an otherwise awesome plugin would be appreciated. I’m glad the rest of the enabled plugins features protected the site

Hey, Jamie– have you tried using the “Truncate” MYSQL command?

TRUNCATE TABLE aiowpsec_userlogin

This should bypass the loading of the 2.8 million rows and just delete them.

Also, we set up simple HTTP authentication using Apache (to have a secondary login box) and this cut down on the brute force attempts.

– Chris

Hi Chris,

This worked like a charm, I ran TRUNCATE TABLE xxx_aiowps_failed_logins (where xxx is my db prefix) and that cleared it out for me.

Cheers!

Jamie

FYI – This plugin already has a WP cron task to automatically prune that table so that it will never get too big.

Maybe there is something on your site preventing wp cron tasks from working properly. Try a series of plugin conflict tests to make sure.

the site doesn’t have a large amount of traffic, so it’s probably why that fell over