Mark Maunder
Forum Replies Created
-
Technically a 503 is the correct response because it means “Service temporarily unavailable” which is what we’re doing. We are making the service temporarily unavailable to someone who’s requests have been throttled for accessing the site too fast or someone who has tried too many login attempts and needs to wait an hour. It also has the added benefit of telling an overly agressive crawler to “come back in a little while” rather than “go away you’re not allowed here” or some other more permanent and potentially SEO damaging response.
I’m sure many out there would like to debate this – they may feel a 403 Forbidden response is more appropriate. I’m also skeptical about you relying on a 302 HTTP response for success and 200 for failed (which really means success in HTTP terms) or even relying on HTTP codes at all to parse login responses. Shouldn’t you be looking at the content because in fact most web apps return a 200 response no matter what the login state and the content indicates the application level result?
I’m getting into the weeds here, but just illustrating how debatable this issue is. So how about we make the response you get a configurable option and you can choose the HTTP code you’d like.
Let me know if you’d like this and we’ll add it in an upcoming release.
Regards,
Mark.
Hi,
I’ve done some investigation on our end but I need more info from you:
Your description worries me. You’re saying that your server is crashing due to lack of memory. I’d like to learn more about exactly what is happening when you see this “crash”.
Is your server swapping heavily and becoming unresponsive?
Is the Linux kernel OOM process killer killing a process for being too large?
How large are the Apache processes that are being killed?
Are you sure you don’t have your server misconfigured to allow too many apache processes or threads for the amount of memory you have?
You jumped to the conclusion that Wordfence is not closing connections correctly and that is the cause of what you’re describing as a memory leak in Apache or PHP. I’m not sure we can jump to this conclusion yet. The operating system is actually responsible for closing TCP connections to remote hosts (it sends the FIN or RST TCP flags), so tell me more about how you drew this conclusion please.
I’m going to make a leap of my own: Is it possible that you’re not running out of memory and your server is not crashing. But instead all your apache threads or processes are busy because of a timeout condition when Wordfence is trying to establish a connection? So if you look at your mod_status page what you would see is all Apache processes stuck in the “W” or “Sending Reply” state?
It sounds like you’re fairly technical so if you can reproduce the issue, please post the output of netstat, top and any kernel logs that may help us understand what’s happening to your server. But make sure you sanitize any sensitive info before you do that.
Regards,
Mark.
OK I’ve filed this as a bug and we’ll get it fixed. What we’re probably going to do is check if the flock() call failed and if it did then we’ll use database level locking or some alternative method that doesn’t involve the file system.
Thanks for reporting this. I’m marking this resolved and we’ll try to get the fix in the next release.
Regards,
Mark.
It looks like your filesystem does not support exclusive locks via the flock() function.
Please log a support call with your hosting provider and ask them what kind of filesystem you’re running. They’ll come back with something like ext3, ext4, NFS or NTFS.
My guess is they’re going to tell you it’s NFS, but please let us know, then we’ll get on this in the lab and figure out a way to do locking on files when you’re using whatever it is you’re using.
Tim will forward the data to me and follow up with you.
Regards,
Mark.
http://codex.wordpress.org/Editing_wp-config.php
Remove the file. WordPress wants you to rename that file to wp-config.php when you install WP. It sounds like the file was copied instead of being renamed.
Regards,
Mark.
Hi,
Unfortunately Wordfence Falcon Engine does not include CDN integration at the moment. However we do work with many CDN’s – we just don’t include features in our product that let you manage your CDN from within Wordfence.
Regards,
Mark.
Hi Matthias,
Those articles are accurately describing the way GZIP normally works. Normally what happens is that PHP sends the output to apache which compresses it using mod_deflate and sends it to the browser.
This varies somewhat depending on your configuration. For example, Nginx might be sitting in front of apache and actually do the compression. But in general PHP executes, sends the output and then the web server does the compression because having a C module do compression is way faster than doing it via PHP code.
However Wordfence grabs your content and caches it BEFORE any web server can compress it. At least this is what normally happens.
In your case it seems we’re grabbing content that is already compressed. This is really weird because it suggests that your content is is being compressed by PHP. I do recall seeing some compression code in WordPress core, but for now I don’t remember what triggers that. I do see a bug that was filed where users were asking for the feature, but it wasn’t implemented:
https://core.trac.wordpress.org/ticket/10365
However I’ve looked through the WP core code and there is gzip compression code in there. So can you please email me your wp-config.php file and remove andy database usernames and passwords before you do. My email is mark at wordfence dot com. I want to try and determine what is triggering this compression.
Also please reference this thread in the email so I know what you’re referring to.
Thanks.
Mark
Please let me know what gives you the impressions it’s Wordfence that is using a large amount of memory – any charts/screenshots/etc that you can post will help us investigate this.
We already unschedule all cron jobs when you uninstall Wordfence. Please let me know, now that you’ve uninstalled Wordfence from the server and presumably deleted all source code, what is happening that leads you to believe that anything related to Wordfence is executing.
Thanks.
Hi,
We had a brief outage during a systems upgrade this evening. Our systems are back online and you shouldn’t have this issue again.
My apologies for any inconvenience.
Regards,
Mark.
Hi Guys,
We had a brief outage this evening during a systems upgrade. My apologies for any inconvenience caused. Should be back up now.
Regards,
Mark.
Hi Dominique,
My apologies, were were completing a systems upgrade this evening which lead to a temporary outage. It should be working fine now. Please let us know if it’s not.
Thanks.
Mark.
Hi Lars,
Are you still receiving those emails? If so can you please go to your Wordfence options page and find out if auto-upgrade is still turned off or if it’s somehow reset?
Thanks.
Regards,
Mark.
Hi Matthias,
Thanks very much for the detailed report. Tim forwarded this to me and I’ve looked at the samples you’ve posted and done some investigation on our own server.
I think something else is compressing your page output and it’s doing it at the PHP level BEFORE falcon receives the data and caches it.
So can you please post a list of the plugins you’re running and I’ll examine the list and try to reproduce this in our lab.
Thanks again for the helpful report.
Regards,
Mark.
Marking this resolved until we hear otherwise. David please feel free to mark this unresolved if you have any data to add that needs investigation by us. I’m happy to do a deep investigation into this but for now it appears to be a server issue of some sort.
Thanks,
Mark.
David to me it’s fairly clear you have an issue with your database and one of the symptoms is that Wordfence is unable to create tables and/or store data in them on your server. I’m unsure how you’re making the leap that it’s Wordfence that’s the cause of your DB issues. We just use the MySQL API as it’s designed – on tens of thousands of sites every day and WF runs fine. Usually when there’s a serious issue you’ll see many other users piling onto this thread with “me too” posts.
So I think you need to investigate your DB. You’ve flagged WF as broken and you’re saying we have an ugly bug, but help me understand what makes you think this has anything to do with Wordfence.
As far as I’m aware, it’s not currently possible for an app using the PHP mysql interface to do something that produces low level table corruption – and if it were that would be a bug in MySQL or the PHP interface, not the PHP app itself.
Regards,
Mark.