It looks like there are two accepted ways of rotating log files on
production, but most of the discussion I''ve found is a couple years
old. Does anyone have an opinion on which of these methods is better
for a Rails 3 app on CentOS? Which method are you using and what are
the drawbacks of it?
1) Inside of Rails:
In config/environments/production.rb, put in something like this line:
config.logger = Logger.new(config.log_path, 50, 1.megabyte)
2) Using logrotate:
create the file /etc/logrotate.d/passenger and put something like this in it:
/home/deploy/app/shared/log/*.log {
daily
missingok
rotate 30
compress
delaycompress
sharedscripts
postrotate
touch /home/deploy/app/current/tmp/restart.txt
endscript
}
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
Okay, I''ll bite and give my $0.02. Method #1 Pros and Cons: Con: I don''t like the application code to be responsible for log rotations. It "feels" like this should be a system administrative task. Pro: Easy to set up and no need to drop a logrotate config in /etc on deployment Method #2 Con: Deployment requires another "external" step (configuration external to the application code itself) Pro: From a sysadmin point of view, I keep all my "log rotation" configuration in one place (as it ought to be). My Preference Method #2: use capistrano or other scripted/automated deployment tool to drop (or update) a logrotate config in your /etc/logrotate.d/ directory to overcome the downside of this method and you''re golden. That''s just my opinion. I''d also be interested in other points of view and better ideas. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> Okay, I''ll bite and give my $0.02. > > Method #1 Pros and Cons: > > Con: I don''t like the application code to be responsible for log rotations. It "feels" like this should be a system administrative task. > Pro: Easy to set up and no need to drop a logrotate config in /etc on deploymentAgreed...> Method #2 > > Con: Deployment requires another "external" step (configuration external to the application code itself) > Pro: From a sysadmin point of view, I keep all my "log rotation" configuration in one place (as it ought to be). > > My Preference > > Method #2: use capistrano or other scripted/automated deployment tool to drop (or update) a logrotate config in your /etc/logrotate.d/ directory to overcome the downside of this method and you''re golden.One drawback to this is /etc/logrotate.d is usually owned by root... do you want capistrano to be able to write to root protected directories? That opens a door for someone to put in a postrotate script that does all kind of nasty things as root :( If it was me, I''d install a rails logrotate file *once* that covered all your deployed applications... something like the below. This way it''s installed once, and never needs to be installed again for any new applications. As long as you make sure the regex''s match all your apps anyway :) /home/philip/apps/*/shared/log/*.log { daily missingok rotate 30 compress delaycompress notifempty create 640 philip philip sharedscripts postrotate if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then /etc/init.d/apache2 reload > /dev/null fi endscript } -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
It seems like the consensus is to use logrotate and handle this completely outside of rails. I tried that yesterday and it worked very easily, so I don''t see any point to using the rails method. Using the wildcard inside the path was one thing I didn''t think of. I thought that I''d have to remember to change the logrotate file for every new app I deploy, but since they follow a pattern, I can say: /home/username/www/*/log/production.log And it gets them all. So I just put this in my instructions with the steps for setting up a new server and forget about it. Thanks! On Mon, Mar 28, 2011 at 2:30 PM, Philip Hallstrom <philip-LSG90OXdqQE@public.gmane.org> wrote:>> Okay, I''ll bite and give my $0.02. >> >> Method #1 Pros and Cons: >> >> Con: I don''t like the application code to be responsible for log rotations. It "feels" like this should be a system administrative task. >> Pro: Easy to set up and no need to drop a logrotate config in /etc on deployment > > Agreed... > >> Method #2 >> >> Con: Deployment requires another "external" step (configuration external to the application code itself) >> Pro: From a sysadmin point of view, I keep all my "log rotation" configuration in one place (as it ought to be). >> >> My Preference >> >> Method #2: use capistrano or other scripted/automated deployment tool to drop (or update) a logrotate config in your /etc/logrotate.d/ directory to overcome the downside of this method and you''re golden. > > One drawback to this is /etc/logrotate.d is usually owned by root... do you want capistrano to be able to write to root protected directories? That opens a door for someone to put in a postrotate script that does all kind of nasty things as root :( > > If it was me, I''d install a rails logrotate file *once* that covered all your deployed applications... something like the below. This way it''s installed once, and never needs to be installed again for any new applications. As long as you make sure the regex''s match all your apps anyway :) > > /home/philip/apps/*/shared/log/*.log { > daily > missingok > rotate 30 > compress > delaycompress > notifempty > create 640 philip philip > sharedscripts > postrotate > if [ -f "`. /etc/apache2/envvars ; echo ${APACHE_PID_FILE:-/var/run/apache2.pid}`" ]; then > /etc/init.d/apache2 reload > /dev/null > fi > endscript > } > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.