[
https://issues.apache.org/jira/browse/ZOOKEEPER-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293154#comment-14293154
]
Rakesh R commented on ZOOKEEPER-1983:
-------------------------------------
Thanks [~shyamal], patch looks fine. Just one thought, with append support the
out file will keep grow. One way is to provide an option of {{MaxFileSize}}
threshold and then rollover based on that, right ? Also, welcome better ideas.
> Append to zookeeper.out (not overwrite) to support logrotation
> --------------------------------------------------------------
>
> Key: ZOOKEEPER-1983
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1983
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.3.5, 3.3.6, 3.4.6
> Environment: CentOS 5.x (and probably any Linux distribution for that
> matter)
> Reporter: Shyamal Prasad
> Assignee: Shyamal Prasad
> Fix For: 3.5.1
>
> Attachments: ZK1983.patch, ZOOKEEPER-1983.patch
>
>
> Currently zkServer.sh will redirect output to zookeeper.out using a simple
> shell redirect.
> When logrotate (and similar tools) are used to rotate the zookeeper.out file
> with the 'copytruncate' semantics (copy the file, truncate it to zero bytes)
> the next write results in a sparse file with the write at the offset of the
> last file. Effectively the log file is now full a null bytes and it is hard
> to read/use the file (and the rotated copies).
> Even worse, the result is zookeeper.out file only gets "larger" (though
> sparse) and after a while on a chatty system it takes significant CPU
> resources to compress the file (which is all nulls!)
> The simple fix is to append to the file (>>) instead of a simple redirection
> (>)
> This issue was found in a 3.3.5 production system, however code in trunk has
> the same issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
