Skip to content

Rodrigo Urubatan – About Code

Helping ruby developers to use the best tools for each job so they can solve hard problems, with less bugs and have more free time.

Menu
  • Home
  • My last presentations
  • About
  • Privacy Policy
Menu

Do you know that idiot that used all the server space with the production.log file? don’t be that guy!

Posted on 2018-06-20 by Rodrigo Urubatan

It is surprisingly easy to configure log rotate to rotate your rails logs, don’t wait until your server is out of space.

I think everyone knows a guy that simply put a rails app online, maybe even used capistrano to automate the deployment, and one year later the app simply stopped working due to lack of disk space.

Then when you go there and find out that the production.log is the biggest file in the server.

That happens because rails will keep appending data to the file, but you probably do not need that much information, the logs from last year are not that helpful, and at least could be stored in a different file.

The simplest solution I’ve found for that is to use the same approach every other linux application uses to take care of the logs, logrotate.

The first step is to edit the file /etc/logrotate.conf, you can use VIM, nano or any other editor of your preference, the content of the file will be like this:

/path/to/app/log/*.log {
  daily
  missingok
  rotate 7
  compress
  delaycompress
  notifempty
  copytruncate
}

What exactly is happening? lets take a look at the log specifications.

  • daily – Rotate the log files each day. You can also use weekly or monthly here instead.
  • missingok – If the log file doesn’t exist, ignore it
  • rotate 7 – Only keep 7 days of logs around
  • compress – GZip the log file on rotation
  • delaycompress – Rotate the file one day, then compress it the next day so we can be sure that it won’t interfere with the Rails server
  • notifempty – Don’t rotate the file if the logs are empty
  • copytruncate – Copy the log file and then empties it. This makes sure that the log file Rails is writing to always exists so you won’t get problems because the file does not actually change. If you don’t use this, you would need to restart your Rails application each time.

To run logrotate manually, to test your configuration, you can use the command: ‘sudo /usr/sbin/logrotate -f /etc/logrotate.conf’

To test the delaycompress, you’ll need to run it a second time.

As you can see, it is really easy to avoid being ashamed by a full disk in production, just use logrotate and be happy 😀

Related

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent posts

  • Why Embrace Nesting in Ruby Modules?
  • An easy way to have a local “Github Copilot” for free
  • SPA without touching Javascript – The magic of Ruby on rails and Hotwire
  • I see Dead Jobs everywhere (sidekiq DeadSet)
  • Quick tips that help: rails notes

Arquives

  • May 2024
  • April 2024
  • February 2023
  • January 2023
  • December 2022
  • June 2021
  • March 2020
  • January 2020
  • July 2019
  • June 2019
  • May 2019
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • February 2018
  • January 2018
  • November 2017
  • August 2015
  • August 2014
  • July 2014
  • August 2007

Categories

  • AI
  • articles
  • cfp
  • firebase
  • gems
  • git
  • opinion
  • presentations
  • projects
  • rails6
  • ruby
  • Sem categoria
  • server-api
  • tutorials
  • Uncategorized
© 2025 Rodrigo Urubatan – About Code | Powered by Minimalist Blog WordPress Theme