Is it needed to add 'O_APPEND' flag here?

[ultraji]

https://github.com/natefinch/lumberjack/blob/47ffae23317c5951a2a6267a069cf676edf53eb6/lumberjack.go#L235

My scene(kube-apiserver audit.log):

1. use logrotate at my workplace to handle log rotation (size > 50M then rotate, copyrtuncate) and make audit-log-maxsize very large (--audit-log-maxsize=100000) so native rotation will not start.
2. if there is no audit.log file before, it will be open by flag 'os.O_CREATE|os.O_WRONLY|os.O_TRUNC'，so when logrotate to rotate the log file, i'm getting binary thrash in log file, and audit.log keeping growing.
3. if there is an exsiting audit.log file before, it will be open by flag 'os.O_APPEND|os.O_WRONLY', so when logrotate to rotate the log file, copytruncate works well, and audit.log is truncated as we hope.

In my test:

I add O_APPEND flag here, everthing work well, and audit.log is truncated as we hope. so is it needed to add 'O_APPEND' flag here?

[natefinch]

Truncate and append don't make any sense together. Truncate truncates, there's nothing to append to.

You said "when logrotate to rotate the log file" ... if lumberjack is writing to the file, you can't have logrotate rotating the file. Lumberjack won't know the file has changed, and will continue writing at the place on disk it last knew to be the end of the file. That's probably the problem. You can't have any other application changing the log file. Only lumberjack can change it.

[ultraji]

I agree that "You can't have any other application changing the log file" .But in my opinion, with O_APPEND flag, "The file is opened in append mode. Before each write(2), the file offset is positioned at the end of the file, as if with lseek(2)", so Lumberjack can know when the file is truncated.