Difference of Apache directives Transfer vs. Custom Log

[Ralph Grothe]

Hi,

I need to devise an automatic rotation of the ever growing access.log from a well visited webserver.
Although this topic must be as ancient as the advent of webservers (was it '92 at CERN?) I first came up with a partly own Perl solution based on Logfile::Rotate
Because of one inexplicable event where one rotation must have lead to the misterious purging of a logfile (it had worked painlessly month before) my confidence in my scripting abilities got shattered so that I retreated to Apache's own rotatelog which I put in a pipe to the CustomLog directive like it was shown in the online manual.
The daily rotation with rotatelog works fine, and those daily excerpts are created.
However growth of the original access_log continues.
After revisiting httpd.conf I noticed that there appeared another directive TransferLog within a virtual server context for the TLS/SSL service that refers to the same global access_log.
Sifting the online manual I only came accross a mentioning that the TransferLog directive was obsolete and should be substituted by CustomLog.
Could it be that the second referencing of TransferLog to the rotated access_log leads to the unbound growth of this file?

[Steven E. Protter]

I'm sure you can handle log rotation in httpd.conf

I'll admit I do not know how.

Here is how I do it on hp-ux

at midngight on log rotation night the following thing happens.

cp access_log /var/access.$date
> access_log

This gets it archieved off and brings it to zero bytes.

Any other methodology deals with problems because the log has almost always got an open process on it.

Linux has a daemon called logrotate, but as far as i can tell, it works just like my manual process on hp-ux.

SEP

[Ralph Grothe]

Hi Steven,

sorry for the belated feedback.
I lost this thread.

I simply removed the superfluous TransferLog directive in the virtual server context in httpd.conf.
From when the parent httpd caught a SIGUSR1 the normal access_log hasn't been written to anymore.

But I'm still unsatisfied with Apache rotatelog's timing of log rotations,
which should take care for that only records from the respective day get written to the log.

These are for example the 1st and last record of such a rotated log:

# sed -n -e 1p -e \$p access_log.20041115
145.254.66.136 - - [15/Nov/2004:01:01:30 +0100] "GET / HTTP/1.1" 304 -
217.231.194.103 - - [16/Nov/2004:00:59:29 +0100] "GET /favicon.ico HTTP/1.1" 404
217

I think I will discontinue with rotatelog and get back to my own scripted log rotation which seems more accurate.

[Ermin Borovac]

Apache's rotation mechanism rotates log files at midnight GMT. From version 2.0.51 onwards rotatelogs utility includes '-l' switch to use local time instead of GMT.

You could also look into utility called cronolog at http://cronolog.org/ which seems to be a lot more flexible.

[Ralph Grothe]

Ermin,

thanks for reminding me that Apache's rotatelog takes UTC1 (RTC) time instead of local wallclocktime.
I would have thought that rotatelog respects settings of TZ.
The environment of root as well as of the uid that httpd forks its children to (usually nobody, or wwww, but in our setting another account that has TZ explicitly set) use this setting TZ=MET-1METDST (i.e. our localtime).
I will have a look at the utility programs of Apache 2.X version, and see if I can use its rotatelog.
However, I cannot change the release of the whole Apache bundle (i.e. 1.3.22) because this is imposed by our customer's application.