PHP Warning: filesize(): stat failed for /xxxxx/wp-content/bps-backup/logs/http_error_log.txt

[WayneM]

Many of my WordPress sites have recently started logging this in error_log:

[21-Apr-2017 11:19:36 UTC] PHP Warning:  filesize(): stat failed for /home/xxxxx/public_html/wp-content/bps-backup/logs/http_error_log.txt in /home/xxxxx/public_html/wp-content/plugins/bulletproof-security/includes/zip-email-cron-functions.php on line 53
[21-Apr-2017 11:19:36 UTC] PHP Warning:  filesize(): stat failed for /home/xxxxx/public_html/wp-content/bps-backup/logs/http_error_log.txt in /home/xxxxx/public_html/wp-content/plugins/bulletproof-security/includes/zip-email-cron-functions.php on line 64

The only thing that may have changed recently on these websites is upgrading PHP from 5.x to 7.0. It seems that this error might be occurring at or around the time that the BPS Security Log had reached the required size for deletion, and when the script encounters a zero sized file on the next check, it throws the error – maybe?

No big deal, but thought this might be something you would want to look at.

Thanks again for the great plugin.

[AITpro Admin]

That PHP error means that the BPS Security Log file: http_error_log.txt is not readable/accessible due to one of these causes below:

https://forum.ait-pro.com/forums/topic/problems-with-security-log/#post-32623

1. The file or folder does not exist.
2. The permissions of the folder where the file is or the file permissions of the file are set too restrictive.
3. The Script Owner User ID (UID) and the File Owner User ID for the: /wp-content/bps-backup/ folder do not match/are not the same.

The folder permissions for this folder should be either 755 or 705:  /wp-content/bps-backup/logs/
The file permissions for this file should be 644 or 604:  /wp-content/bps-backup/logs/http_error_log.txt
All folders under your website should have the same Script Owner User ID (UID) and the File Owner User ID.

You can check folder permissions and Script Owner User ID (UID) and the File Owner User ID on the BPS Pro System Info page.

And of course a 4th cause:  If the Sucuri Restrict wp-content access Hardening Option is still enabled or the Sucuri htaccess file here:  /wp-content/.htaccess was not actually really deleted and still exists.  If the Sucuri wp-content folder .htaccess file still actually exists you will need to manually delete it using FTP or your web host control panel file manager.  It is possible that the Sucuri Revert hardening button does not actually really work.

[WayneM]

I just double checked all the parameters you indicated above, and everything meets the required settings.

The Security Log page indicates: “File Open and Write test successful! Your Security Log file is writable.”

The file currently shows:

BPS SECURITY LOG
=================
=================

According to the System Info page:
The folder permissions for the noted folders are 755
Script Owner User ID (UID) and the File Owner User IDs are all the same.
cPanel verifies the folder is chmod 755, the http_error_log.txt file is chmod 644
I am running the Free version of BPS. I do not have any Sucuri options. There is no /wp-content/.htaccess file.
Would it be helpful for me to email you a screen capture of my System Info page, or any other information?

-Thanks

Follow-up thought…

Here’s what I think might be happening: When the log file is deleted, there is a period of time when the file really does not exist and no security issues happen that would trigger creating/writing the file. During this period, if the cron fires, there really is no file to check. I also think that when I visit the Security Log page of BPS when there is no current log file, the visit to that BPS page triggers the creation of the new file with the standard starter text:

BPS SECURITY LOG
=================
=================

I may very well be completely wrong on all of that conjecture. But, it’s a curious issue in any case…

[AITpro Admin]

The time frame where a Security Log file would not actually exist would be in milliseconds.  ie 100 milliseconds or .1 seconds.  So maybe that is what causes the php error.  The general rule of thumb with php errors is if they are occurring constantly/repeatedly then you need to fix whatever is causing the php error.  If everything is working correctly and a php error is insignificant and it is only occurring once in a while then you can ignore those php errors.

[WayneM]

To the best of my limited abilities and guesswork, I’m pretty sure I’ve confirmed that what I proposed in my “follow-up thought”  is correct.

I run an hourly check of file changes on all my sites by using the WordPress File Monitor plugin. The error logs for my lower traffic sites do indicate the noted error, and the error happens every hour until such time as a new http_error_log.txt file is created. I just confirmed this by looking for the http_error_log.txt file using cPanel file manager. The file did not exist. As soon as I visited the BPS Security Log page for that website, the new http_error_log.txt was created.

I understand that this is not an important issue, it is just an annoyance and a curious glitch that happens when the file is deleted. It clearly is not being recreated within milliseconds, but rather is only created when a BPS admin page is visited, or a security issue needs to be logged.

Thanks again for the BPS plugin. I’m sure it has helped keep my websites more secure. 🙂

[AITpro Admin]

This is the normal functionality of Security Log automation:
When your Security Log file reaches the file size that you have chosen (256KB, 500KB or 1MB) in your BPS option settings it is automatically zipped, emailed to you and replaced with a new blank Security Log file.  This automation is done by using a standard WordPress Cron job that runs once per hour and checks the size of your Security Log file.

Example:  Let’s say you Security Log file is currently 100KB and you have chosen 500KB for the size limit to automatically zip, email and replace your Security Log file with a new blank Security Log file.  The hourly cron job will check the size of your Security Log file and since it is below 500KB the Security Log file will NOT be zipped, emailed and replaced.  If your Security Log file is over 500KB then it will be zipped, emailed and replaced by the automated hourly standard WP Cron job.

So it sounds like something on your website (plugin or something else) or something on your web host server (scanner or other security measure) is automatically deleting the BPS Security Log file or breaking normal Security Log automation.  A known issue with some web host security measures:  The BPS Security Log has the capability to capture entire hacker scripts used to attack your website if you do not check this checkbox setting:  Limit POST Request Body Data.  Some web host security measures either automatically quarantine or delete the Security Log file if it contains hacker code and then usually send an automated email that malicious code was found in the BPS Security Log file.  The solution for that known issue is to check the Limit POST Request Body Data checkbox setting.  If a BPS Security Log file does not exist a new Security Log file is automatically created when you login to your website and visit any page in your WordPress Dashboard area.  So the problem is that something is automatically quarantining or deleting your Security Log file.  Check with your web host first to see if they do anything like that.  If your web host is not causing this problem you will need to figure out if another plugin is causing this problem.  If a plugin or your theme is not causing this problem then other possibilities could be things like:  you have disabled standard WordPress Crons on your website, which is breaking BPS Security Log automation or the worst case scenario your website is hacked and the Security Log file is being deleted by a hacker Shell script.

[WayneM]

The BPS Security Log page has an option to “Delete Log File” when it reaches x size. That’s the option I’m using on all my websites. It clearly works. But, BPS does not create a new log file until a BPS admin page is visited, or a log file entry needs to be written. Thus, the log file may not exist when the cron job goes to look for it – this causes PHP error. Maybe the delete file action, should be to make the file size zero instead. That way, there will be no error on checking if the file exists 🙂

[AITpro Admin]

Then there is something on your website that is preventing BPS from copying a new blank Security Log file when the automated Security log cron job runs.  Are you disabling standard WP Crons on your website? Which web host do you have?

Normal Security Log automated functionality when the Delete Log File option is chosen:  Let’s say you Security Log file is currently 100KB and you have chosen 500KB for the size limit to automatically delete and replace your Security Log file with a new blank Security Log file. The hourly cron job will check the size of your Security Log file and since it is below 500KB the Security Log file will NOT be deleted and replaced. If your Security Log file is over 500KB then it will be deleted and replaced by the automated hourly standard WP Cron job.

[WayneM]

Host: Crocweb.com
Server Type: LiteSpeed
Operating System: Linux
WP Filesystem API Method: direct
Server API: litespeed CGI Host Server Type
DISABLE_WP_CRON constant: Standard WP Crons are not disabled on your website.
PHP Version: 7.0.17

[AITpro Admin]

hmm ok well I am out of logical guesses then.  The only logical things I can think of that would cause this problem would be a file/folder permissions problem or WP Crons are disabled problem.  I rechecked the BPS code that handles Security Log automation to make sure there are no new bugs and everything works fine on my testing server and no php errors.  So obviously the problem has to do with something you have installed on your website (plugin or theme or custom script) or something your web host server is doing (security measure or something else).

[AITpro Admin]

We will add another condition that checks if the Security Log file exists, which will stop the php errors from occurring, but that has nothing to do with the real problem, which is that the hourly Security Log cron job is being broken by something on your website or server and the new blank Security Log file is not being copied successfully in the hourly Security Log cron job.

[Author]

Posts