Log Files are not rotating

M

modem

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

I was doing some much delayed work on my server getting everything updated, streamlined, etc. When I got to my /var/log directory I was surprised to see that my log files were in the hundreds of megs, with my var/log/maillog being 1.5GB in size!!!

While the size isn't an indicator that there is a problem, I did check to see the last time the files were created and they were created on March 30 2006. Appearantly they have not been rotating weekly. What I want them to do and what they were doing from the beginning was erasing the log after the time period was up, backing it up to a logfile.1, .2, etc and creating a new logfile.

Does anyone have any ideas what might be the problem? The cron jobs *look* OK.
 
Yes, crond is running per this line from ps ux:

root 3104 0.0 0.0 1604 348 ? S Mar27 4:14 crond


As for the specific cronjob, I was wondering how exactly DA has it's log file rotations setup.

As for what cronjobs there are, here is my cron listing:

root Yes /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
Yes /etc/cron.weekly/makewhatis.cron
Yes /usr/local/bin/php -c /usr/local/directadmin/plugins/jtbox/shared/php.ini /usr/l ...
Yes /usr/local/directadmin/dataskq
Yes echo 'action=vacation&value=all' >> /usr/local/directadmin/data/task.queue;
No /sbin/quotaoff -a; /sbin/quotacheck -augm; /sbin/quotaon -a;
Yes echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
Yes echo 'action=reset&value=all' >> /usr/local/directadmin/data/task.queue
Yes echo 'action=check&value=license' >> /usr/local/directadmin/data/task.queue
Yes /usr/bin/mrtg /etc/mrtg/mrtg.cfg
Yes /usr/local/sysbk/sysbk -q
Yes /etc/webmin/time/sync.pl
unreal Yes /home/ircd/unreal/Unreal3.2/ircdcron/ircdchk >/dev/null 2>&1
anope Yes /home/ircd/anope/services/services.chk >/dev/null 2>&1
 
I checked my process list and found syslog running:

2843 root 0.0 % syslogd -m 0


However when I checked the cronlist, there was no syslogd job there in the cronjobs. Should it be there? If so, what is the code for making it run properly?
 
syslogd is fine; it's why your logs are getting so big.

logrotate is the cronjob that should be rotating the logs.

Jeff
 
What's the exact syntax to use for the logrotate command in the cronjob list?
 
logrotate can and will differ between OS distributions.

Here's mine, from CentOS 4.4:
Code: 
#!/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
In mine, perhaps more important is the contents of the /etc/logrotate.d directory; mine is:
Code: 
acpid
apache
cups
exim
mgetty
mysql
named
ppp
proftpd
psacct
rpm
snmpd
syslog
up2date
yum
...and also the contents of my /etc/logrotate.conf file:
Code: 
# 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.
Jeff
 
Thanks for that info. I went back through and checked the system and found this:

1.) My logrotate.conf file is identical to yours.
2.) logrotate *is* in a cronjob called /etc/cron.daily/logrotate which is supposed to be performed at midnite each night.

3.) The /etc/cron.daily/logrotate script is exactly the same as yours.

4.) My /etc/logrotate.d dir contains the following:

apache
cups
mgetty
named
psacct
rpm
syslog
yum
apf
exim
mysql
proftpd
redhat-config-network
snmpd
up2date

I checked inside the exim file and found that it has the /var/log/exim/mainlog, ../processlog, ../rejectlog, and ../paniclog listed there.

Those logs haven't been rotated since March 13 when I checked the mainlog.1, .2, etc.

I also noticed I have /var/log/maillog which was used today and it's getting a whopping size of 778MB. Along with the /var/log/messages is getting in the 600mb range and it hasn't been rotated since March 13 as well. Other logs such as /var/log/cron and /var/log/secure are in the 200-300mb size range and they too have not been rotated since Feb-March.

Any ideas on how to proceed and or force the rotations to start?
 
modem said:
I also noticed I have /var/log/maillog which was used today and it's getting a whopping size of 778MB. Along with the /var/log/messages is getting in the 600mb range and it hasn't been rotated since March 13 as well.
Click to expand...
Those aren't big :) .
Any ideas on how to proceed and or force the rotations to start?
Click to expand...
Try running the logrotate script manually:
Code: 
# /etc/cron.daily/logrotate
If this works, then figure out if crond is running.

Jeff
 
Yeah I know those files sizes aren't *that* large or *that* bad, but it is to me an indicator nothing has been done since March. :P

That command definitely did work because the logs rotated instantly. I went back and checked my startup scripts and crond is listed there as being activated/started during system boots. I went in and ran the command ps ux and saw crond running there, but decided to issue the service crond restart command. It successfully shutdown and restarted.

Is it possible for it to be there listed as working when it's not?
 
Not generally.

See if you get a rotate the next time you're supposed to.

Jeff
 
As a quick experiment, I setup a cronjob on my server to handle the IRCd dameon. The cronjob was to check to see if the IRCD is running every 15 minutes and issue a restart command if it isn't. I shutdown the IRCd a few hours ago and so far no restart. I wonder if there is something screwed up with cron?
 
Also I noticed that now since I was working on this log issue on Nov 26, that the logs are *not* available inside of DA's website statistics area.

I checked the /home/<user>/domains/<domain name>/logs area and saw that it looks like the main log file hasn't been modified on anyone's account since Nov 26. When doing a check on that directory, I see something like this:

Nov-2006.1.tar.gz root/root 25-Nov
Nov-2006.2.tar.gz root/root 26-Nov
Nov-2006.3.tar.gz root/root 27-Nov
Nov-2006.5.tar.gz root/root 23-Nov
Nov-2006.tar.gz root/root 24-Nov


Is all of this because I restarted the cronjob and it's set to rotate the logs on a weekly basis? Or is this something that MRTG takes care of? I saw a cronjob for it happening every 5 days, but, that doesn't explain how it displays data for each previous day's worth of website hits?
 
Hi Modem,

How did you fix this problem. I am having the same exact problem and i have done everything Jeff and you suggested.

Thanks

Dec
 
Ok i think i found the problem. There is this bug for the version of logrotate that comes by default with Centos 4.1 (logrotate-3.7.1-5.RHEL4.i386.rpm):

Updated logrotate packages that address various bugs are now available.

The logrotate utility simplifies the administration of multiple log
files. Logrotate allows for automatic rotation, compression, removal, and
mailing of log files.

This erratum addresses the following bugs:

* Logrotate cannot execute any script if /tmp was mounted using noexec.

* The description of the logrotate "extension" option in man page
logrotate(8) did not correspond with the real behavior.

All users of logrotate should upgrade to these updated packages, which
resolve these issues.
Click to expand...

http://rhn.redhat.com/errata/RHBA-2006-0696.html

The solutions is to download and update logrotate RPM (logrotate-3.7.1-6.RHEL4.i386.rpm) from here:

http://mirror.centos.org/centos/4/fasttrack/i386/RPMS/

I will be checking tomorrow to see if it fixed the problem.

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