Save Disk Space By Setting Up Logrotate with Your Ghost Blog

The Ghost blog platform doesn't automatically set up logrotation when it is installed. As a result, Ghost will perpetually append to its log files until you run out of disk space. Here is how to fix it using the logrotate utility in Linux.

I've noticed that when I backup my Ghost server's content, rsync seems to hang as it moves one particularly large file: the Ghost production access log found in /var/www/ghost/content/logs/. Checking the Ghost log directory, I was surprised to find a single log file consuming several gigs of disk space.

If you're self-hosting Ghost, chances are you have the same problem. (Whether you know it or not).

The cause? Local Ghost installs don't configure logrotation, so Ghost just perpetually appends to its log files in perpetuity until you run out of disk space.

The Solution: Logrotate Configuration

Here's how to fix it using the logrotate utility in Linux:

sudo nano /etc/logrotate.d/ghost

Add the following to your new Ghost logrotate configuration:

/var/www/ghost/content/logs/*.log {
	weekly
	rotate 12
	compress
	copytruncate
}

What does the above configuration do?

• weekly - Tells Linux's logrotate utility to rotate the logs weekly. Other options available to you include: daily, monthly. Technically there is an hourly option, but by default logrotate runs as a daily cron job, so hourly won't really do you any good.
• rotate 12 - Tells logrotate how many logs to keep on rotation; in this case, twelve.
• compress - Logrotate will compress old/archived logs as they are rotated. You should do this unless you have a specific reason not to: i.e. you need to routinely access the archived logs
• copytruncate - This is key when using Ghost. In my troubleshooting with logrotate for Ghost, I found that Ghost needs to be restarted when rotating the logs, otherwise it will continue to write to the old (now rotated) log files, which is not what we want. The copytruncate directive truncates the original log file in place after creating a copy. It's the copy that then gets rotated and compressed. This is a much more elegant solution than restarting the Ghost service (which consequently will interfere with your blog as Ghost is restarted and introduces the risk that your site goes down if the Ghost service fails to restart).

That's it! You have now both saved some disk space going forward and also protected your server against uncontrolled logfile inflation with the Ghost CMS/blogging platform.

Testing

Now, if you want to test this out and make sure everything is working, I recommend the following:

For testing purposes, set the above configuration's "weekly" directive to "daily" or even "hourly". Note that logrotate is a daily cron job so you may have to wait a day or two to see any changes.

Can't bring yourself to wait 24 hours? You can also force logrotate to run with:

sudo logrotate /etc/logrotate.conf -vf

Checking your Ghost logs with ls -la /var/www/ghost/content/logs should show something similar to the following:

Additional Reading

If you're interested in reading my notes and seeing the thought process I went through before settling on this configuration, you can check it out in The Engineer's Workshop Forums here:

PSA: Lack of Log Rotation Configuration in Ghost Server Can Eventually Consume All Disk Space

Whenever I backup my Ghost content, I’ve noticed that rsync seems to hang as it moves two particularly large files- specifically the log files found in /var/www/ghost/content/logs/. (You can read more about my Ghost backup process here: Backup Your Ghost Content to unRAID). Looking at the directory…

The Engineer's WorkshopTorqueWrench

I plan on doing a complete guide into Linux's logrotate utility in the future. So check back in later!

As always, if you need any help or have any questions, please ask!