log4j fileappender doesn't switch to the new file when logrotate rotates the log file

Question

Context:

I want to use log4j to write audit-related logs to a specific log file, let's say audit.log. I don't want to use syslogappender(udp based) because I don't want to be tolerant to data loss. Plus, I am using logrotate to rotate the audit.log when the file gets to certain size.

Problem:

I am encountering is that, when logrotate rotates the file audit.log to audit.log.1, log4j keeps writing to audit.log.1 other than writing to the audit.log.

Possible approaches:

1. I know I can use rollingfileappender to do the log rotation other than use logrotate, so when rollingfileappender rolls the file, it switch to the new file without hassles. But the reason I can't use rollingfileappender is that I want to use logrotate's post rotate feature to trigger some scripts after the rotation happens which can't be provided by rollingfileappender.

2. Another desperate way I can think of is to write a log4j customized appender myself to close the log file(audit.log.1) and open the new one(audit.log) when it detects the file is rotated.

3. I never used ExternallyRolledFileAppender, but if it's possible to use logrotate post rotate to send the signal to ExternallyRolledFileAppender and make log4j aware the file is rotated, and start writing to the new file?

Question:

Just wondering is there some appender like that already been invented/written? or do I have other options to solve this?

Bogusz

Perfect way of asking a question +1 – Morningglory

Answer 1

Check out logrotate's copytruncate option, it might help your case:

copytruncate
       Truncate the original log file to zero size  in  place
       after  creating  a copy, instead of moving the old log 
       file and optionally creating a new  one.   It  can  be  
       used  when  some  program  cannot be told to close its 
       logfile and thus might continue writing (appending) to
       the  previous  log file forever.  Note that there is a
       very small time slice between  copying  the  file  and 
       truncating  it,  so  some  logging data might be lost.
       When this option is used, the create option will  have
       no effect, as the old log file stays in place

Default

For some reasons, I can't use copytruncate in my case. If I explain that to you, it will take me half an hour to write it:) so any other options I have? – Bogusz

feel free to take half an hour... :) @Bogusz – Burdensome

Perhaps it's the nearest fit, but it doesn't solve the problem, as by copytruncate logdata may be lost. Is there really no way to tell an log4j app to reopen its logfile handles? – Eyebolt