Recently, a client of mine running eCommerce on WordPress was faced with a bit of a dilemma. Due to a plugin conflict, their error log file grows at a staggering rate, eventually consuming all available disk space and crashing their site. I know as a developer, my first step when they reached out to me was to check the error logs. The first time I checked, the log file was over 80GB!

Let’s talk a bit more about the setup here. They host with Codero on a VPS and manage everything through PLESK (gross). They run WordPress with WooCommerce.

We had to take a phased approach here to solve the problem. I’ll be talking about phase one: Create a job to remove the error_log every 3 days. That’s the scope right there. Pretty simple! It doesn’t fix the overall issue: Why is the error log filling up so, much so fast? That’s my next phase (another day). Okay, let’s explain what needs to be done.

  • Create a shell file with a script to remove the error log
  • Create cron job to execute shell file every 3 days

I’ve messed with shell files in the past, but this was my first time creating one from scratch.

I wanted to do this in a way that would allow me to easily add or remove files from the script. To easily recognize the file, I named it log_cleanup.sh. You could use a text editor and upload it, but could run into issues so I just created it directly on the server using nano.

Navigate to any directory you want and execute the following command:

nano log_cleanup.sh

This should open an empty nano CLI file editor. Now we can build out the script. I want my script to email every time it runs so you’ll see some variables in here for that. I want to declare a timestamp and the files that I want to remove:

#!/bin/bash
# File created by Chrs Benjamin - chrisbenjamin.co
# This script is to clean up log files known to cause storage issues##### Setting timestamp for notifications

TIMESTAMP=$(date +%x_%H:%M:%S:%N | sed 's/\(:[0-9][0-9]\)[0-9]*$/\1/')

##### List file locations
file1="/path/to/logs/error_log"
file2="/path/to/system/logs/error_log"

Now, I want to create an array containing the file variables I just created:

##### Create array for above listed file locations
array=($file1 $file2)

Like I mentioned earlier, I want this to be as easy as possible to edit in the future. All I will have to change are the file variables and adding/removing those files from the array. Now i want to create the portion of this script to remove the files:

##### DO NOT CHANGE ANYTHING BELOW THIS LINE
##### Start delete process
echo "Deleting log files..."
echo "Files:"
for item in ${array[*]}
do
rm $item
printf " %s\n" $item
done
echo "${#array[*]} log files deleted..."
printf "Job completed at: $TIMESTAMP %s\n ${#array[*]} log files deleted. %s\n %s\n ${array[*]}" | mail -s "Log cleanup successful" chris@chrisbenjamin.co

I added the echo lines to see what’s happening if I want to run the script manually. These files are constantly being used by Apache which means when we delete them, the space they took up is not yet available. In order to free up that storage, we must restart Apache:

##### Restart apache to free storage
service httpd graceful

The file is complete! It’s all fairly simple if you have any experience working with shell scripts. All that’s left for us to do is create the cron job. Some hosts allow you to add a job through their web portal. In this case, I had to do this through CLI utilizing crontab. It starts with etiting your crontab:

crontab -e

This should open the default system editor. I want my job to run every 3 days at midnight, so my crontab looks like this:

SHELL=/bin/bash
HOME=/
0 0 */3 * * /path/to/log_cleanup.sh

After finished editing the crontab, I ran crontab -l to see that the content I added was saved. That’s it! I ran ./log_cleanup.sh and was emailed the results. The script will attempt to run whether the file exists or not. If the file doesn’t exist, Apache will still restart which still is never really a bad thing (opinion) considering it takes 1-2 seconds to come back up.

I know I will utilize this same process in the future whether it’s to remove a file or maybe execute some php files. I like how I can just manipulate the file variables and edit the array. The more I think about it, the more my wheels are turning coming up with the cool things I could do. I hope this will inspire others as it has inspired me!

Let me know what you think in the comments.

Laravel 5 + Dreamhost
Laravel has great documentation which is only one reason I love working with it so much. With that said, it has some dependencies that require a bit of research and configuration to get it installed. With a little bit of trial and error (and Google) I was able to get it set up. The issues that I had were mostly because of the host, not Laravel itself. Others may not have the same issue that I had, but I’ll walk through what I needed to to to get it up and running.

INSTALLATION
Laravel utilizes composer to install/run. Composer documentation explains two ways to install.

curl -sS https://getcomposer.org/installer | php

or

php -r "readfile('https://getcomposer.org/installer');" | php

I had issues with both┬ábecause every time I tried to run the command, I’d get an error saying I was running php 5.2.17. Running php -v showed exactly that. Now, I know when I set up the hosting for the domain I selected PHP 5.6 FastCGI. Composer requires PHP 5.3 or later. I took to Google to see if anybody had the same problems and see what I needed to do to resolve it. Without changing the default version being used, you would have to type out the entire location of the php version you want to use. In my case I would have to write out:

curl -sS https://getcomposer.org/installer | /usr/local/bin/php56/bin/php

I really don’t want to do that every time I need to perform a php command. So, I found a couple of different posts where users changed the default php version for CLI. This site explains what I did, only I am using 5.6 instead of 5.3.

$ mkdir -p ~/bin
$ ln -s /usr/local/bin/php-5.6 ~/bin/php
$ echo "export PATH=~/bin/:\$PATH" >> ~/.bash_profile
$ echo "export PATH=~/bin/:\$PATH" >> ~/.bashrc

After starting a new session and running php -v shows that CLI is now using PHP 5.6 as default.

Problem 1 solved! But there is more…

After successfully installing Composer, it was time to install Laravel. The composer.phar executable is whatever directory you installed Composer in. In my case it’s the root of the domain I’m working in (/home/[username]/[domain-name]/).

The next step in the Laravel documentation tells you to download the Laravel installer via composer with the following command:

composer global require "laravel/installer"

Unless you have a previous application using the .phar extension, that command is likely not going to work. To enable the phar extension, it was pretty simple. This will require a phprc file. I found some good direction from this site:

$ mkdir -p ~/.php/5.6
$ echo "extension = phar.so" >> ~/.php/5.6/phprc
$ echo "suhosin.executor.include.whitelist = phar" >> ~/.php/5.6/phprc
$ php -m | grep Phar

Now, instead of the exact command Laravel tells us to use, I followed this method to get it to work:

php composer.phar global require "laravel/installer"

In the Laravel example to create a new project you can use “laravel new” or stick with the composer way like I did with this command:

php composer.phar create-project --prefer-dist laravel/laravel blog

This will create a new directory /blog in your domain. We just have to install the laravel dependencies now. Only, my final problem is I didn’t install composer as a global command. It only works in the directory that I am currently in. In order to install the laravel dependencies, composer requires a composer.json file which exists in the new directory that just got installed.

There may be a better way to do this, but for the sake of time and impatience, I just copied the composer.phar file to my new /blog directory:

cp /home/[username]/[domain-name]/composer.phar /home/[username]/[domain-name]/blog/

[showad block=1]
The final step is to go to your new /blog directory and run the composer install command:

cd blog
php composer.phar install

Depending on how you have your host setup, you can go to http://yourdomains.com/blog and should see the landing page for your new Laravel application. If that doesn’t work you can go try going to http://yourdomain.com/blog/public and you should see it then.

That was the process for me. It seemed a bit complicated, but it’s so worth it in the end. I am a problem solver and I just couldn’t let each little speed bump stop me from getting Laravel installed. Now, I am on the latest version and love it! I will be sure to show off the app when it’s in beta and ready for testing.

Let me know if this helped you at all. I’d love to hear feedback and challenges other may have faced in the installation process.