Topic: logs getting huge - do i need a chainsaw?

[allun]

Can anyone comment on whether this seems "normal"?
 - My logs all seem to rotate as they should, but the current log seems to just keep growing - it goes back to december last year..... do i have a problem?


-rw-r--r--    1 squid    squid        1.3G Feb 18 19:31 /var/log/squid/access.log
-rw-r--r--    1 squid    squid        565k Dec 21 04:02 /var/log/squid/access.log.1.gz
-rw-r--r--    1 squid    squid        509k Dec 14 04:02 /var/log/squid/access.log.2.gz
-rw-r--r--    1 squid    squid        455k Dec  7 04:02 /var/log/squid/access.log.3.gz
-rw-r--r--    1 squid    squid        475k Nov 30 04:02 /var/log/squid/access.log.4.gz
-rw-r--r--    1 squid    squid        426k Nov 23 04:02 /var/log/squid/access.log.5.gz

[genzil]

I looks like the log isn't being rotated.

Try and have a look through the logrotate config files and see if there is a problem there.  You may require your logrotate config file to be rebuilt.  Some one else may be able to help with that.

As I write this I also remember some thing about squid and logrotating being a bit difficult becuase of they way it works, but again some one else will have to help here.

You may also be able to find the answer by looking in the log files for the cron (and messages file).

Thanks

Craig

[grand-pa]

Allun, what version of SME do you have ?
Is there the same problem with /var/log/messages (for exemple) ?
Is cron running : service crond status ?
What is the response of this command : ls -l /etc/e-smith/events/actions/purge-old-logs ?

[Anonymous]

Thanks for the replies guys -

grand-pa:  SME version 6.0final, and cron is running fine according to "service crond status", also i have several things that report to me and they are all checking in...
The purge-old-logs script is there and runs ok:

-r-xr-xr--    1 root     root         2351 Feb 16  2002 /etc/e-smith/events/actions/purge-old-logs

the logrotate script is in crontab and runs when it's meant to and rotates the logs but seems to leave the current log growing in size - shouldn't it rotate them then delete the current log?

Is anyone able to point me to how to rebuild the logrotate config as suggested by genzil? It looks correct in itself:

-----------------------------------------------------------------

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

-----------------------------------------------------------------


should i try making a backup of the access.log and making a new (empty) file in it's place?

TIA


Allun

[grand-pa]

Try to run manualy the script /etc/e-smith/events/actions/purge-old-logs : it's the script that has to rotate the "dated" logs (every 1/8/15/22/29 day of the month, at 01h12, it should delete logs older than 35 days).

That's why i asked you if the other "dated" logs have the same problem : if only access.log has this problem, we can suppose that the process of log-rotation isn't guilty.

[allun]

OK,
I have found it - and i think this will affect a few other people too so here are the details as clear as i can explain them:

A few months ago i installed the snort/acid contribs from  Ari Novikoff (http://www.marari.net/).  The version i used is the current one - http://www.marari.net/downloads/snort/sme-acid-2.0.0-1ari.noarch.rpm.

I encountered the logrotate problem as detailed in this thread : http://forums.contribs.org/index.php?topic=9231.msg35102#msg35102
however until just now i didn't realise that if there is an error as logrotate steps through the files in /etc/logrotate.d/ the logrotate process stops at the point of the error.

So since the logrotate.d files are processed in alphnumeric order, and /etc/logrotate.d/snort was failing with an error, logrotate was never getting to the next file - /etc/logrotate.d/squid, and THAT is why my squid access.log was 1.3GB!  

I fixed the /etc/logrotate.d/snort file, ran /etc/cron.daily/logrotate manually, and hey presto my squidlogs got rotated just fine.

Thanks to grand-pa for making me think in a different direction - I noticed it was only the squid logs that were having this problem, and connected that with the only thing I learned in school - which is  that sQ comes after sN in the alphabet!