Log files not rotating/clearing.

M

modem

Verified User
Joined
Apr 7, 2004
Messages
355
Hello all,

In the process of working on/solving another issue, I was shocked to see the size of several of my log files. I checked from the DA log viewer and confirmed log sizes by using a console command, and indeed they are extrodinarily large.

What stuck out to me is the size of the logs vs how much traffic the server is getting. The server is a small single webhosting server that is no where near overloaded or swamped with customers or traffic. This made me wonder if some of these logs like my 1.34 GB exim log aren't getting erased after say a week period.

Here are my logs:

/var/log/cron - 124.4 MB
/var/log/directadmin/error.log - 50.8 KB
/var/log/directadmin/errortasq.log - 1.59 MB
/var/log/directadmin/security.log - 42.0 KB
/var/log/directadmin/system.log - 484 KB
/var/log/exim/mainlog - 107.1 MB
/var/log/exim/paniclog - 148 KB
/var/log/exim/rejectlog - 11.2 MB
/var/log/httpd/access_log - 140 KB
/var/log/httpd/error_log - 5.61 MB
/var/log/httpd/suexec_log - 147 KB
* /var/log/maillog - 1.34 GB
* /var/log/messages - 343.5 MB
* /var/log/proftpd/access.log - 9.88 MB
/var/log/proftpd/auth.log - 0.935 MB



I also went back through and checked my cronjobs on the server and there does not appear to be anything there that is setup to clean out logs after a predetermined amount of time.

What would I need to create in the cronjob area to ensure that these larger logs get cleaned out? The only cronjobs that are running are the following:

/etc/cron.daily/yum.cron
/etc/cron.daily/rpm
/etc/cron.daily/slocate.cron
/etc/cron.daily/logrotate
/etc/cron.daily/makewhatis.cron
/etc/cron.daily/00-logwatch
/etc/cron.daily/tmpwatch
/etc/cron.daily/prelink
/etc/cron.weekly/makewhatis.cron
/usr/local/bin/php -c /usr/local/directadmin/plugins/jtbox/shared/php.ini /usr/l ...
/usr/local/directadmin/dataskq
echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
/sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue
/usr/bin/mrtg /etc/mrtg/mrtg.cfg
/usr/local/sysbk/sysbk -q
/etc/webmin/time/sync.pl
 
Last edited:
logrotate should be taking care of that and is in the list you pasted. It might just need configuring or the threshold for rotation hasn't been met yet. It's been awhile since I've checked that out.
 
I checked the logrotate file and this is what I found:

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0


For ExitValue, is that where I would use a number for the length of time that logs need to be rotated?
 
You don't change EXITVALUE; it's the value the script checks to see if the logrotate program ran properly.

Jeff
 
Thanks. The .conf file only had basic instructions on handling generic system files, but nothing specific to DA based systems and associated log files. It will give me a good starting point of testing and implimenting this.

Thanks!
 
Keep in mind DirectAdmin itself handles apache logs, so you won't have to worry about those.
 
Jon, I just looked at a DA server and there is a script for apache in /etc/logrotate.d/.

Are you saying your servers don't have that?

Jeff
 
Yes, there is configuration for apache there, but as far as I know DirectAdmin still takes care of (forces) the rotation since I don't remember a work around ever surfacing. I'm not sure if there's a dependency on logrotate for apache logs.

Here's the feature information on that:http://www.directadmin.com/features.php?id=483
 
Last edited:
Another thing to keep in mind about logrotate. It creates scripts by default in /tmp and executes them to do some of the rotation. If you have /tmp mounted with noexec then logrotate won't function correctly. You can change the temp directory with the TMPDIR environment variable set in your /etc/cron.daily/logrotate file. Make it point to a directory that does have execute permissions.
 
I went back in and checked inside of /etc/cron.daily and found that there was a logrotate script file there. Inside of there was a script file with root/root permissions and a 0755 level. Inside of that file was the following:

#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0


From there I went into the /etc/logrotate.d folder where I found all the various scripts that are executed by logrotate. I opened up the syslog script file and found the following:

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}



It shows that the above logfiles are working as they should, rather they still are not parsing out data after a week or predetermined amount of time. I really need to get this taken care of before the 1.6gb logfile turns into 2, 3, 4, 5gb in size.
 
Don't worry, they probably won't grow above 2 Gigabytes; usually that's where the server crashes :mad: .

You might want to see if the script is really running.

Add something to it that'll send you an email when it runs; Perhaps the email should consist of the log directory.

Jeff
 
I checked the manpages for logrotate and it has a mail feature that lets it mail the log to be before the log is erased, after it's created, etc. Either way mailing a 1.6gb log is outta the question.

Is there a command to run the same time as the cronjob that sends a text mail to show that it has been performed?
 
Jeff - I may have found a possible solution to my BSMTP problem. That is once I moved/renamed the old log files and created new ones, everything seemed to be operating normally. However I did that manually via console, I'm going to try your suggested measure of making sure the logs are rotating. Appearantly the last time they were rotated was the last week of Feb 2005!!

I'm not holding my breath on this one, but I'm going to let it run in this configuration overnight and see what happens.
 
Keep us posted.

But I don't think in the long run that BSMTP issues have to do with logfile size; most of us have log files that rotate as they should.

Jeff
 
You must log in or register to reply here.
Back
Top