Have any of your files in /usr/local/apache/logs ever rotated?

[ozzi4648]

Since installing cpanel on some of our server, we noticed the logs in /usr/local/apache/logs/* growing out of control without ever being rotated. In /etc/logrotate.d the script called "apache" is the reason why. Its totally wrong. Its looking for files located in /var/log/httpd/ and that is not where my log files are located. In fact, we dont even have files in this directory. Its completely empty.

The first line:

/var/log/httpd/access_log /var/log/httpd/agent_log /var/log/httpd/error_log /var/log/httpd/referer_log {

should be changed to, at the very minimum;

/usr/local/apache/logs/access_log /usr/local/apache/logs/agent_log /usr/local/apache/logs/error_log /usr/log/apache/logs/referer_log {

You could leave out agent_log and referer_log since i dont see those as even existing in my /logs/* directory.

In addition you may want to add the follow to the list above

ssl_engine_log
suexec_log

and any other file you find needs to be rotated in this directory.

logrotate.conf

In /etc/logrotate.conf where is the reference to lastlog? The default apache log includes a rotatation of lastlog but i didnt find an entry in my logrotate.conf.

My /var/log/lastlog was around 19megs so add the following to logrotate.conf so the added entry looks like this.

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

/var/log/lastlog {
monthly
rotate 1
}

# system-specific logs may be configured here


SSL logs:

If your running ssl on your server you will find some huge log files in /var/log if you have never rotated them. Ours was hitting 51megs. Your SSL log files will match the name of your hostname or the name of your certificate or both depending on how many SSL certs you have running. You could also add those above.

Also, do you really need to keep 4 sets of rotated logs? I rarely refer back that far unless i have some problem and i need to go back to view the logs but usually going back 1 or 2 weeks of rotated logs is sufficient. I have changed my number of backup logs in logrotate.conf to 2. Old rotated logs even going back 4 weeks could take up huge amounts of disk space if there was alot of activity. Consider compressing the rotated logs. Simply uncomment #compress which will compress your old rorated logs.

Now whats happening to xferlog? It was being rotated at one stage but no longer. The last time it was rotated was back in Nov 22 of 2002 on my box. Since then the file has grown to 25megs and not rotated. So was it lost somewhere in all the cpanel updates? One will never know since i cannot find any reference anywhere to it being rotated. If this is also the case on your box do this. If anyone knows where its being rotated let me know because i cannot find it

cd /etc/logrotate.d

is there proftpd in that directory?

FIX;

in the logrotate directory create proftpd

pico or vi proftpd

add;

/var/log/xferlog {
postrotate
/bin/kill -HUP `cat /var/profptd.pid 2> /dev/null` 2> /dev/null || true
endscript
missingok
}

Save it. Not tested but it should work.

That should take of most of the rotation that Cpane is just not doing. Cpanel 6 HELLO! can we have these fixed?


:D

 

[jimcarter]

Very useful info, thanks

 

[Juanra]

I thought that these got deleted by Cpanel itself (unless you check the option not to delete them in WHM settings). Making rotations configurable from WHM would be a good thing to implement imho.

 

[payne]

I found the following routine in cpanellogd, which is run once a day:

sub rotatelogs {
my($logsize);
my(@LOGS) = ("/usr/local/apache/logs/suexec_log",
"/usr/local/apache/logs/access_log",
"/usr/local/apache/logs/error_log",
"/usr/local/apache/logs/referer_log",
"/usr/local/apache/logs/agent_log",
"/usr/local/apache/logs/ssl_log",
"/etc/httpd/logs/error_log");
foreach my $filename (@LOGS) {
next if (! -f $filename);
my $size = (stat($filename))[7];
my $threehmegs = (1024*1024*300);
my $fivemegs = (1024*1024*5);
if ($size > $threehmegs) {
open(FILE,"$filename");
seek(FILE,($size-$fivemegs),0);
open(NFILE,">$filename.new");
while(<FILE>) {
print NFILE;
}
close(FILE);
close(NFILE);
unlink($filename);
system("mv","-f","$filename.new","$filename");
system("killall","-USR1","httpd");
print "Apache Log Cleaned { Size was: $size }\n";
}
}
}


This seems like a poor attempt by cpanel to keep some logfiles cut down to a manageable size.

What I see this doing is checking all of the mentioned log files to see if they are bigger than 300MB and then reducing them by 5MB if they are. This algorithm would break down if these logs grew more than 5MB/day. While it would be deleting *some* logs, it wouldn't keep up.

 

[Noldar]

FYI lastlog

You don't need to rotate /var/log/lastlog. It's not a normal log file it's a "sparse file" that's actually much smaller than it looks. It tracks the last login of each user and will only grow when you add a new user. Do a

du -h /var/log/lastlog

and you'll see it's actually much smaller than what ls -lh reports.

Richard