Mantis - Resin
Viewing Issue Advanced Details
3024 minor always 10-27-08 17:06 11-04-08 09:13
emil  
ferg  
normal  
closed 3.1.7  
fixed  
none    
none 3.1.8  
0003024: Log rotation problem
(Rep by Richard Grantham)

    I've got a major issue with our live servers. The logs don't appear to
    be rotating correctly. This is filling the disk and causing performance
    issues.

    Resin is running as the resin user - therefore will have reduced
    permissions but, even so, this shouldn't be happening as that user is
    the owner of the folder that is being written to.

    Any ideas on how to sort this or is it a bug?

    [root@xxxx logs]# ls -l
    total 3431672
    -rw-r--r-- 1 resin apache 1073979392 Oct 15 11:30 access.log
    -rw-r--r-- 1 resin apache 1073745275 Oct 15 00:50 access.log.20081015
    -rw-r--r-- 1 resin apache 1073892465 Oct 15 00:52 access.log.20081015.0052
    -rw-r--r-- 1 resin apache 49848320 Oct 15 00:54 access.log.20081015.0054
    -rw-r--r-- 1 resin apache 0 Oct 15 00:56 access.log.20081015.0056
    -rw-r--r-- 1 resin apache 0 Oct 15 00:58 access.log.20081015.0058
    -rw-r--r-- 1 resin apache 0 Oct 15 01:00 access.log.20081015.0100
    -rw-r--r-- 1 resin apache 0 Oct 15 01:02 access.log.20081015.0102
    -rw-r--r-- 1 resin apache 0 Oct 15 01:04 access.log.20081015.0104

I'm running Resin 3.1.7a. My log configuration is as follows:
<log name="" path="logs/resin.log" timestamp="[%Y-%m-%d %H:%M:%S.%s] "
rollover-period="1D" />
<stdout-log path="logs/stdout.log" timestamp="[%Y-%m-%d %H:%M:%S.%s] "
rollover-period="1D" />
<stderr-log path="logs/stderr.log" timestamp="[%Y-%m-%d %H:%M:%S.%s] "
rollover-period="1D" />
<access-log path="logs/access.log" format='%h %l %u %t "%r" %s %b
"%{Referer}i" "%{User-Agent}i"' rollover-period="1D" />

We don't run Resin with Apache as we use a hardware load balancer.

What I see happening is the log being rotated but a file handle is
maintained on access.log (it's all the logs mentioned above this is
happening with, not just access.log) and not recycled after the log is
rotated. The result is that the log is copied to another file but then
not cleared. It continues to be written to. Hope that makes sense.

Notes
(0003532)
ferg   
11-04-08 09:13   
The JNI code wasn't properly linking nativeTruncate, which meant the log rotation was not able to clear the old log file.