File Change Warning without changed files

@marc

How many files exist in the uploads folder ? 10s, 100s, 1000s 10000s

Also is there any file data (option_value) stored for the itsec_local_file_list_3 or itsec_local_file_list_4 option_name entries in the wp_options table ? Log into phpMyAdmin and execute the following SQL command to find out:

select * from wp_options where option_name like ‘itsec_local_file_list_%’;

And finally please post the content of the file change detection email which is received every day. If you don’t feel comfortable posting that info in this topic you can also simply forward a copy to me [ redacted, support is not offered via email, Skype, IM etc. only in the forums ]

dwinden

Hi,

the uploads folder has some thousand files (3000 – 4000).

The file_list_3 entry is empty (a:0:{}), all other file_list entries do have lists of files.

What I found out when looking at the mail is that it lists around 550 files that were added (not changed or deleted), and these files are all non-images (pdf, zip, …).

Mail starts with:

A file (or files) on your site at https://www.domain.xx have been changed. Please review the report below to verify changes are not the result of a compromise.

Scan Time: Friday, October 16th 7:08 am UTC
Files Added: 551
Files Deleted: 0
Files Modified: 0
Memory Used: 0.78 MB

and than the list of files as mentioned above.

Thanks again,
Marc

@marc

Ok, all that info confirms what I already suspected.

I think you are running into a MySQL config issue that I’ve seen before.
Possibly the max_allowed_packet is too low … (Default 1MB or 4MB depending on the MySQL version used).

Increase the MySQL max_allowed_packet value and this issue will probably
go away. Good chance you even no longer need to run the File Change Detection scan in chunks …

To confirm for 100% this is the cause of your issue check your web server error_log file.

You wil find errors in that file that look very similar to these:

WordPress database error MySQL server has gone away for query UPDATE wp_options SET option_value = ‘a:1330:{…}’ WHERE option_name = ‘itsec_local_file_list’;

WordPress database error MySQL server has gone away for query INSERT INTO wp_itsec_log (log_type, log_priority, log_function, log_date, log_date_gmt, log_host, log_username, log_user, log_url, log_referrer, log_data) VALUES (‘file_change’, ‘8’, ‘File Changes Detected’, ‘2015-06-06 14:01:38’, ‘2015-06-06 12:01:38’, ”, ”, ‘0’, ”, ”, ‘a:4:{s:5:\”added\”;a:1330:{…}s:7:\”removed\”;a:0:{}s:7:\”changed\”;a:0:{}s:6:\”memory\”;s:4:\”2.13\”;}’);

dwinden

Hi dwinden,

thanks for the info. I already asked my hoster how this setting can be changed.
From a query in PHPMyAdmin I saw the value is set to 64M at the moment.

Is there something I can do, if this value is not changeable at my webspace hoster?

Thanks for your help,
Marc

@marc

hmmm … a value of 64M (I presume MB) should be more than enough …
No need to increase such value … I seriously doubt you would run into the FCD issue I described in my previous post with such a high max_allowed_packet value already set …

I noticed you say you ran a query from phpMyAdmin to get the current max_allowed_packet value … You don’t actually need to run any query.
Simply goto the ‘Variabelen’ (I’m Dutch) menu option and search for the max allowed packet (without underscores) variable. Its value is listed in bytes … please doublecheck.

Another approach would be to weed out all those files … simply reduce the files footprint in the uploads folder (if possible).

Did you have a look at the web server error_log file ?
It is the only 100% way to determin whether you are experiencing the issue I think you are … you definately have all the symptoms but I have my doubts regarding the 64M …

dwinden

Hi,

sorry for the delay, I had to wait for the answer of the hoster.
The error_log does not contain an error message similar to the one mentioned above.

But it looks like the task rans into the max_execution_time and is automatically aborted by the server.

At the moment I wait for the answer of the hoster (again) to check, if this limit could be changed, but I think that will not be possible.

So I think the only chance I have is to reduce the number of files in the upload folder.
Any suggestion how to find unused files in the folders?

Thanks,
Marc

Hi Marc,

No problem.
I reviewed this topic yesterday and I also concluded there must be some other factor than the max_allowed_packet at work here.

The PHP max_execution_time indeed is a good candidate.
Just like the PHP memory_limit …
Check both current values on the iTSec plugin Dashboard page.
Scroll down to the System Information metabox, PHP Information section.

It must be something that interrupts\aborts the FCD script …

Any suggestion how to find unused files in the folders?

I think you will need to use a method like fifo (first in first out).
By default the uploads folder is organized in a year\month folder structure. Simply remove the oldest folders\files first.

Another idea is to profile the FCD script execution and then optimize the FCD code to make it run faster.
I’m specifically thinking of the file filtering that takes place.
There are 3000\4000 files in the uploads folder but only 551 of those are actually scanned for file changes (which is not much).
I guess there is some serious processing taking place there … (recursion).
Well actually only profiling the entire FCD script will tell us where the script could be optimized best …

dwinden

PHP Memory Limit: 100M
PHP Max Script Execution Time: 30 Seconds

Not the worst settings for a webspace hoster, but still many files to check.

I will try to remove unneeded files, there are some plugins to identify unused images…

Thanks for your help so far!

It would be cool, if it would be possible to configure the FCD script even more, e.g. defining more individual chunks (specify upload sub folders for every chunk) to reduce the script runtime.

Marc

Marc,

Ok, please note, when executed the FCD script checks the current memory_limit value and if it is set to a lower value than 128M it will temporarily increase the value to 128M.
So in your case the memory_limit value is (temp) increased to 128M at the start of FCD execution.

If the issue is caused by max_execution_time and your hosting provider refuses to increase its value, theoretically you could use the PHP set_time_limit() function to reset its value.
This would need to be done inside the FCD script.
Not one of the first options to try but lets keep this in mind.
We don’t even know for sure its a max_execution_time issue …

Something else, could you give me an overview of the number of files scanned in the other 6 chunks ?
You can get this info from the other FCD emails received.

The reason why I’m asking is because 551 files in the uploads folder is not much. I think there are more files scanned in the folder(s) of other chunks … (but probably less files filtered out). And it seems to work there …
So there must be something special about the uploads folder …
It could be the folder structure in combination with filtering (many) files out.

How does the folder structure in the uploads folder look like ?
Default, year\month, or are there even more levels … ?

dwinden

uploads contains 3400 files in typical year/month structure (starting 2014/07 with 1400 files in that folder, all other folder have a maximum of 250 files).

There were no changes in the last days in the other chunks, so I didn’t get any mails, but the one other chunk with the most files is the chuk including wp-content/plugins with around 2500 files.

The difference between these files is, that the files in the uploads folder are probably larger.
Interesting to see is that the mail with the log of changed files only lists non-images, although there are way more images in the uploads folder. Perhaps the files are checked one mime-type after another and images are checked first.
So the number of 550 files is perhaps the number of non-images in all folders…

Marc

Marc,

Interesting to see is that the mail with the log of changed files only lists non-images, although there are way more images in the uploads folder. Perhaps the files are checked one mime-type after another and images are checked first.
So the number of 550 files is perhaps the number of non-images in all folders…

The FCD Ignore File Types setting controls which file types are ignored during a FCD scan.
When I mentioned filtering in my earlier post(s) I was referring to this.
The iTSec plugin considers image files (.jpg, .jpeg, .png) to be safe.
Just like log (.log) and translation (.mo, .po) files.

So the 550 for the uploads chunk are the truly scanned files in the entire uploads folder. Considering the total amount of 3400 files, most files seem to be filtered out as image, log or translation types.

I bet there are not that many files filtered from the wp-content/plugins folder as it will mostly contain .php and .js files. However the wp-content/plugins folder will contain an even more complex folder structure. So folder structure alone does not seem to contribute to this issue. Nor does number of files.

We need an indication of what goes wrong. Otherwise we keep running in circles. I think I figured out a way to get the actual error.

So far this problem was revealed by scheduled FCD scan results.
It is also possible to run a manual FCD scan from the File Change Detection section on the iTSec plugin Settings page.
But we need to make sure it runs for chunk 3 (the uploads folder).

So try this:

1. Temporarily change the existing wp_debug line in wp-config.php from false to true.

2. Log into phpMyAdmin and click on the wp_options table.

3. Run the following SQL query:

select * from wp_options where option_name = ‘last_chunk’;

4. Doubleclick on the resulting option_value cell and edit the value (if necessary). Make the value 2. (When running the manual scan 1 is added to the current last_chunk value -> 3).

5. Click anywhere outside the cell to save the change.

6. Click on the blue Scan Files Now button at the top of the File Change Detection section of the iTSec plugin Settings page.

At this point there is a good chance we will get an error displayed.
But also don’t be surprised to see the scan complete with no errors …

(Don’t forget to undo the wp-config.php change from step 1).

I’ll keep my fingers crossed … ??

dwinden

OK,

the option is not called ‘last_chunk’ but itsec_file_change and last_chunk is part of the serialized data within, but I found it and changed it.

Although wp_debug was set to true, there was no debug output at all.

What happened:
– I manually started the check of the next chunk
– after some time, the check was finished and I was able to click again on “Scan next chunk”
– the scan was not listed in the log
– the last_chunk changed from 2 to 3
– I clicked again on “Scan next chunk” and after a short time, the message “No changes were detected” appeared. This scan is also shown in the list of scans (with 0 changed, added or deleted files).

Because it looks like debugging is quite difficult in this environment, I recommend to at this point.
I know that the customer will move to another server very soon and probably we’ll have more possibilities to debug there, if the problem still exists there at all.

Thanks a lot for your time and ideas!

Marc

Ok, excellent.

My apologies for not being accurate. I was a little bit in a hurry.
But I see you were able to manage things yourself.

So, it seems you were able to run 2 consecutive manual FCD scans.
One for chunk 3 and another one for chunk 4.
And even though there was no error displayed clearly the scan for chunk 3 is still failing as there is no result whatsoever reported on screen (and no email?).
(I guess option_name itsec_local_file_list_3 in the wp_options table is still an empty array in the database … which is not correct).

But the scan for chunk 4 seems to work fine.

Well at least we’ve tried.
Hopefully this nasty issue will disappear once moved to another server.
If not simply update this topic.

dwinden