Recently it came to our attention that a site we administer was creating literally thousands of temporary ZIP archive files every day, which was fine since that site relied on dynamic file downloads and creating temporary files was how the site handled this functionality. However, the problem arose when we found out that none of these temporary files were being removed ever. Logic would dictate that the number of temporary files stored on the server wouldn’t really matter, since each temporary file was only 1KB or 2KB in filesize and so it would take literally a million of these temporary files to start making a dent in the server’s hard drive space.
However, GoDaddy shared hosting puts an arbitrary limit on the number of files you can store on a given shared hosting account–silly I know, but can you really expect anything less of GoDaddy? I am a fan of their products but they do sneaky stuff like this in order to monetize their services–there’s just no way around that. For future reference, GoDaddy’s shared hosting plan put a 250,000 file limit on the shared hosting plan we were working with. Approaching this limit carried the threat “You’re at your resource limits. Visitors might have trouble accessing your site.”
So, all in all, a temporary file creation and storing issue that shouldn’t have been a problem for years was becoming a problem much faster than anyone had expected. How were we to solve this problem, you ask? Simple! Create a file deletion script with PHP that deletes the oldest file in the temporary files folder, and then use Apache to run that PHP script once per minute so that we can slowly and methodically remove old and irrelevant temporary files without much work. Creating the script was easy for anyone that knows simple PHP commands, and it could easily be run through a web browser to delete the oldest temporary file properly.
However, when assigning a Cron Job to that script (a Cron Job is an Apache command that can run a server-side file or operation at given intervals), the Cron Job’s output was simply “Permission Denied.” Cross-referencing the FTP structure confirmed that the script, which worked for deleting files in a web browser, was not working when being run by the Cron Job. “Permission Denied,” indeed.
We had to implement a two-step process to correcting this problem. The main and probably obvious solution was navigating to the PHP script in question with an FTP client, and literally changing the permissions to 777. I found our deletion script with 644 permissions–in other words, there were no permissions to execute this file when that was it’s purpose all along.
To be extra sure, after changing file permissions to 777, I modified the Cron command to include the text “php” with a space before the command itself, thus forcing that command to be run as PHP as it was intended. All in all, the successful Cron command looked something like: “php /home/user/public_html/website/[SCRIPT TO RUN].php”. Once these fixes were implemented, Voila! The automatic deletion script was running properly once per minute and everything was back to normal. The out-of-control temporary file situation was once again a manageable system.
Mission Bay Media is a San Diego Web Design and Development firm located in the Pacific Beach neighborhood of San Diego. Call them at 858-356-2820 to see how we can turn your web presence into the wild success it was meant to be.
