I spent the last few hours, OK, maybe longer, addressing a .ea-php-cli.cache does not exist issue I kept running into. Let me explain.
After months of complete backups being run at my WordPress site level and regularly being sent to my off-site storage, I suddenly began receiving BackupBuddy Error email notifications.
Don't panic, what does the notification say?
At first, I thought if I ignored it, maybe it would resolve itself – hey, come on... sometimes it does with a quick release update! But when it doesn't resolve itself with a quick update, I have to remind myself, "Don't panic, what does the notification say?" Let's take a closer look and see if we can figure out what's going on.
Well now... here's a place to start.
Well now... here's a place to start. Select "View recently made backups" from the BackupBuddy Backups page to find this backup and view its log details and/or manually create a backup to test for problems.
I try to run the backup manually to see if I can get it to run. It doesn't. Find another clue.
Naturally, I try to run the backup manually to see if I can get it to run. It doesn't. Find another clue. Upon closer examination, I find a clue within the log. (To get to the log go to your WP admin dashboard > BackuBuddy > Backups > Click on the log tab.) Here's what I find:
09:43:44.69 0.58sec 52.16MB Error #4001: Unable to successfully generate ZIP archive. Backup FAILED.
See logs above for more information.
09:43:44.69 0.58sec 52.15MB ERROR: Failed function `backup_zip_files`. Backup terminated.
a 4001 error and a message with a link
OK, the log reveals a 4001 error and a message with a link so I click the link and am redirected to the iThemes Codex. The codex is awesome if you know what to look for but in this case, the information provided was still too ambiguous to lead me to where I needed to be. Get more information.
Get more information.
Next, I see that the log itself sheds some light with the message, "See logs above for more information." So, I do. I find:
09:43:44.65 0.54sec 52.27MB Zip process reported: PCLZIP_ERR_MISSING_FILE (-4) :
File '/home/cPanelUN/public_html/.ea-php-cli.cache' does not exist
Missing file? Does not exist?
I see a URL path and a note stipulating that the file does not exist. So, the step I take is to see if maybe something just went haywire while updating recently. I go to get a fresh copy of BackuBuddy, install, and activate the plugin on the site. Try to run the backup again. C'mon, work! Wait for it, wait for it... FAIL, same error.
OK, so it is not a file from BackupBuddy and it says I have a missing file. Well, let's go look on the server and determine if this is a true statement and if the file is missing.
Low and behold, it IS there, it does exist.
I log into my cPanel and navigate to where the file should be. And low and behold, it IS there, it does exist. Then I have this sudden realization... Oh no!
Have I been hacked?
Hmm, I don't know what this file is and I have not been getting this message or had this problem before. Has my site been hacked and some random malicious file been injected right into my server? Yikes! Just what I need... not!
So, like any inquiring mind wants to know, I open the file to see what it is. I am fully expecting to see some hack, injection, or encrypted code of some sort. Only to find that the file is empty! So, I am relatively certain it is not a hack.
Well, darn. Now I have to deactivate all my plugins to see if there is a plugin conflict. If I don't try this approach and I try to submit a support ticket, support techs are going to tell me to try deactivating all my plugins! OK, OK. After deactivating all the plugins except BackuBudy, I attempt to run the backup again. Here we go again. C'mon, C'mon... FAIL, same error.
Grrr! This is the point where you realize you are spending time doing things that HAVE to be done, that you don't really want to do, and that you most certainly prefer to be doing something else!
Time to ask for help.
Time to ask for help from someone who will hopefully know something more than me about this. I write to iThemes support with all of the details I know about WP version, BackuBuddy versions, what I've tried, etc. If I don't tell them, they won't know and they'll tell me to try all of the stuff I have already done and that will waste at least a half of a day's time!
By the way, be nice to support people when you need them - they really are trying to help. As frustrating as having to get support is, it is nice to know that iThemes has an awesome support staff.
Anyway, back to the story. I got the following reply from iThemes support regarding the error.
I believe the file is in some way related to "EasyApache" which I assume is something you use under your hosting package?
The error that you are seeing above is essentially the WordPress zip handling library saying that it cannot access the file which in turn implies that the host PHP installation is unable to access the file.
Exactly why PHP is unable to access the file is hard to say but generally, it is either because such file is "transient" in some way or otherwise there is some ownership/permissions issue that makes the file inaccessible.
It is not a BackupBuddy issue but simply an issue with the accessibility of the file - assuming it is not a transient file then the WordPress zip handling library may simply interpret an inability of PHP to acmes the file as the file not existing as the return result of the PHP file functions when asked to access an inaccessible file may well be the same as if asked to access a non-existent file.
But in any case - whilst you may or may not chose to find out a bit more about the file from your host support (it is indeed always a good idea to know about "strange" files that may be present in your public hosting space for obvious reasons) as it is not actually related to your WordPress site I would simply use the File & Directory Defaults exclusions picker (or the profile specific exclusions picker if you are using per-profile exclusions) to exclude it from the backup as you would not require it whether or not it is accessible. This can often be the case with various files and folders that appear in a site hosting space but actually are not part of the WordPress site installation and would not be required on a restore/migrate.
To the Point of Living Dangerously
Well, I was to the point of living dangerously and decided to try removing the file. It worked! I was able to run a back up just fine. Doing a little happy dance.
But something told me I should dig a little deeper so, I decided to check with my hosting company (Liquid Web) and find out more about this .ea-php-cli.cache file.
I was interested in learning more because of what the iThemes tech mentioned but also because of what I saw when I looked in my file manager for the file. I understood that the period or dot before the file name indicated that it was a hidden file. But, perhaps the most intriguing thing was that when I accessed my file manager for the site in question and saw that file there, I also saw something different about this particular file that I had not seen before. There was some other little label type thing being cut off between the file icon and the file name.
Here's what I found out from my server tech support chat.
The file is a required file for WHM/cPanel and EasyApache 4. It determines the php version of a site, so there will be no issues with site operation if you remove it, but it will interfere with the EA4's ability to propagate PHP version changes. Here is the accompanying documentation on the topic: https://documentation.cpanel.net/display/EA4/EasyApache+4+and+the+ea-php-cli+Package
The Consequences of Living Dangerously
OK. Now I had a real dilemma. I had removed the file but I certainly wanted to keep the server functionality that the file supplied. I should be able to just recreate the file, right? Well... no.
Once the file is removed and if you want to add it back in, there is a process. It's a binary file. Ah ha! So that is what that other odd little label type thing was indicating! In any case, to replace the file, the hosting company will need to regenerate it through EA4 (no clue what EA4 really is other than knowing it is something on the server side of things).
Best Practices and the Resolution
Interestingly, I now have another site that is experiencing this same pattern, Time to come up with a process to address this. Great! My resolution and best practice process for what seems is going to become a recurring issue for the way I have my server and sites configured is to set BackUpBuddy to exclude the file.
You’d think that this would be a pretty simple process. Go to the WP admin dashboard, navigate to BackupBuddy >Settings, and move the file into the exclude list. But no, there's more... and where it becomes a little bit more interesting.
The file does not show up in the list within BackupBuddy as a file to exclude. You have to add it manually. And although BUB clearly states to “exclude files & directories (relative to WordPress root)” and, “One exclusion per line. Enter RELATIVE to your backup root,” what is not clear for the average person having to do this manually is what RELATIVE really means or how to ensure what you add is "relative." This was even confusing for the tech at LW helping me (who other than this was completely competent and helpful).
To get it to work, we had to add it like this:
And that's it... well, almost.
At the same time that I was excluding the file on my end of things, the tech was forcing the configuration file to be remade and in the process, it remade the link and properly set permissions and other settings.
Because we were both doing things simultaneously, we're not 100% sure which action resolved the issue or if both actually needed to be done. So I will do my part and add the name of the file to be excluded manually and if I am still having problems after that, I will contact my hosting provider and request them to “force the config.”
Finally, we were able to properly resolve this issue.
Additional Information and Update:
I continued working with the support team at iThemes to determine why the file did not show up in the exclusion list. Here is what we found...
Having looked at the site I think the reason for the item not appearing in the exclusions picker is because it is a broken symlink - which is to say the file itself is a symlink that "points" to another file/directory but what it points to does not exist. When I tried to access the symlink through my ftp client it gave me the name of the thing it was trying to access (what was pointed at) but said it did not exist. I was just looking again but see that the symlink has disappeared now.
Under some circumstances the fact that the symlink was broken wouldn't matter but in the case where the standard zip system in compatibility mode is being used then even if the option to ignore/not-follow symlinks is selected (this is the default) the way we have to work with the WordPress zip handing library means this will still fail as it did - if the symlink were not broken then it would be ignored but also it would be available for exclusion.
It is a bit of a corner case and can currently be accommodated as it was by manually adding the exclusion but I'll have a look at beefing up the exclusions picker functionality to better handle broken symlinks to make it simpler to exclude them.
So what does all that mean to you and me? Well, bottom line is that there are some circumstances that caused the file to not show up and iThemes support is going to try to add those circumstances into the BackupBuddy plugin to attempt to "catch" them and display them when these circumstances occur. Thank you iThemes!
If you run into this problem and would like to have a little hand-holding to get you through the process, just let me know. I can be reached through Clarity or my support system for a call or appointment for any online business assistance. I'd love to help you make some sense of things that might have you a bit frazzled or frustrated. For me, it's just another day.