Simple Question (deleting production.log)

[Chris Sund]

Hey group,

This is a simple question but I want to make sure I don't bring down
tent. I was just looking at my production.log file and it's pushing
3gb (yikes). I want to remove it, but I'm not sure if I should...

a.} delete it
b.} rename it
c.} do some other fancy thing.

I just can't remember if when I delete it, if they system
automatically creates a new one, or if I have manually create one so
the system doesn't throw an error. I was going to give it a try on a
simple rails app, but thought I would throw the question out here
first.

Any advice is welcome, and I don't care about the info in the file. I
want to gracefully reset the file.

Thanks!

Chris

[AJ ONeal]

cat /dev/null > /path/to/logfile

AJ

Sent from my Google Android

--
Utah Ruby Users Group
ur...@googlegroups.com
http://groups.google.com/group/urug/
- All meeting times and places can be found here.

** Please prefix your subject with "[JOB]" if your message is about job opportunities.

[Brad Midgley]

sh shorthand for truncating... :)

$ >log/production.log

I believe rails will seek to the end before writing the next log entry
(if it didn't then it would end up with a large hole in the file
before the next write so ls still shows the large file size...) use du
<file> if in doubt to get the real disk usage.

> --
> Utah Ruby Users Group
> ur...@googlegroups.com
> http://groups.google.com/group/urug/
> - All meeting times and places can be found here.
>
> ** Please prefix your subject with "[JOB]" if your message is about job opportunities.
>

--
Brad Midgley

[BJ Neilsen]

I would say save it if you think you'll ever need to go back through and run stats or bug hunting off of it. For myself, I've rarely had to do either of those things past a few days, so if it were me I'd just trash it. You can just truncate it like AJ and Chris showed. Another alternative is to setup logrotate[1] on the file, which will automatically rename and create a new file once the file hits a certain size (or on a certain schedule). Set it and forget it.

Thanks,
BJ

[1]: http://gd.tuwien.ac.at/linuxcommand.org/man_pages/logrotate8.html

[Dave South]

For development: run "rake log:clear"

For production on Linux server, set up logrotate.

Typically we run our applications on a non-root account on the server.

Create directory ~/.logrotate
Create file ~/.logrotate/logrotate.conf

If your linux account was called "appuser" and your application was
called "app":

# rotate logs
/home/appuser/app/shared/log/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
copytruncate
create 0640 appuser appuser
}

This will cause logrotate to "rotate" your logs every day, compress
them after the second day, remove them after 14 days.

Dave

[Dave South]

Whoops. Forgot about the script to run logrotate:

Saved as ~/bin/rotatelogs

#!/bin/bash
/usr/sbin/logrotate -s /home/appuser/.logrotate/logrotate.status \
/home/appuser/.logrotate/logrotate.conf

In the appuser crontab (crontab -e)

5 2 * * * /home/appuser/bin/rotatelogs

Runs logrotate script every day at 2:05 AM

Dave

[Matt White]

Chris,

If you don't need the contents of the log anymore and you're using the
standard Rails logging setup, you can do:

rake log:clear

If you want to keep your logs and not have to have this recurring
problem, the logrotate, as suggested by BJ.

Matt

On Jun 24, 10:18 pm, Chris Sund <ch...@silhouettesolutions.net> wrote:

[Chris Sund]

Thanks Group! I did "> production.log" to get by and need to setup the
logrotate, that's seems to be the best solution.

[Tim Harper]

Chris, I heavily recommend you invest some time in learning syslog.
It will do log rotation for you. It also can log which processes
emitted which messages, and collect all logs from your servers to a
single box for your viewing pleasure (we employ rsyslog, a drop-in
replacement for syslog, for the task).

Further, you'll have the option to use tools to analyze your logs,
like zenoss or splunk.

Tim

[Tim Harper]

A further advantage of using syslog that's worthy of mentioning is the
fact that it decouples your server processes from storing log messages
to a file. This means if you have several processes writing to the
same log file, you don't have to restart them all or signal them to
create a new file descriptor pointing to the fresh, unrotated log
output file (whereas without doing this, if you rename production.log
to production.log.1, all processes that were previously writing to
production.log would continue writing to production.log.1)