djason

Thanks. I talked to our host and they made the following change (for anyone else with the same issue). The errors have gone away.

In the site’s php.ini file, add:

session.save_path = “/tmp”

Agree, I don’t need notifications that updates are available. WordPress already does that.

Ok, I understand. Thanks for your patience. The confusion arrives from Wordfence’s two different uses of “block”. The rate limiting rule’s “block” is handled differently (not htaccess).

So this is partially moot since Falcon is being discontinued, which I just found out about today. This is very disappointing. I spent countless hours researching caching and now I will need to do it over again. However, we won’t be upgrading anytime soon because of the effort so I still need to understand and what’s going on. And it might apply in the future.

That answers part of my question, but the other part still seems to conflict with the documentation:
https://docs.wordfence.com/en/Falcon_Cache#Falcon_Engine

“With Falcon enabled we block IP’s in your .htaccess”

However, as I understand it, if something is blocked in the htaccess, then the request will never even make it Wordfence, so it wouldn’t be able to log the attack. Or do only *manual* blocks go in the htaccess? Thanks, we’re close!

Let me clarify. I haven’t looked at this since the original post so I am going on memory here. We are using the Falcon engine so when an IP is blocked, the block is set in the htaccess. When the person breaks a firewall rule, WF states it’s blocking the IP. If the firewall rule is broken *after* they are being throttled, there is no block in the htaccess. If a firewall rule is broken *before* they are throttled, the block *does* show in the htaccess file. If you need logs or screenshots or something for me to show this, I can, but it may take awhile, esp. since I would need find an occurence of this.

Bump. Still seeing the same issue.

Any thoughts?

I believe admin-ajax is called when someone is looking at the Wordfence admin pages. By default, it refreshes every 2 seconds. This is what i saw in my Apache log, too. If you change the refresh too something less frequent, the messages might stop.

https://docs.wordfence.com/en/Wordfence_options#Update_interval_in_seconds

(I was looking for a simliar topic because sometimes the scan is flagged as suscpicous)

If you are using the Wordfence Falcon caching engine, the block should be in your htaccess file so that requests from the IP never even make it wordpress.

Anyone? I don’t know if it’s WordPress’ new forum sorting order, but after I posted the thread was not listed on the first page or two.

I am seeing the same issue on our main site, with multiple hits per second sometimes. What exactly is the syncAttackData doing? Is it a core feature or something we can disable? I haven’t checked the logs for all our sites, but the one site that I know is having this issue is also the only one that sees a substantial (for us) amount of malicious activity. We are using 6.1.14 on WP 4.5.3.

I am having the same problem. The issues seems to be wp_cron does not run in the background:

https://www.ads-software.com/support/topic/set-cron-job-in-my-plugins?replies=4

I did not see this on my production site because I use a monitoring service to check it every 5 minutes. However on my staging site, it was only running when someone accessed the site.

If you don’t have a site that is constantly being accessed, it looks like you’ll need to select one of the other job start options or set up a monitoring tool, which seems to work well, though it’s not exact. Plus or minus a few minutes.