[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072096#comment-14072096
 ] 

Hadoop QA commented on ZOOKEEPER-1983:
--------------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12657189/ZK1983.patch
  against trunk revision 1612906.

    +1 @author.  The patch does not contain any @author tags.

    -1 tests included.  The patch doesn't appear to include any new or modified 
tests.
                        Please justify why no new tests are needed for this 
patch.
                        Also please list what manual steps were performed to 
verify this patch.

    -1 patch.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2220//console

This message is automatically generated.

> 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
>         Environment: CentOS 5.x (and probably any Linux distribution for that 
> matter)
>            Reporter: Shyamal Prasad
>            Assignee: Shyamal Prasad
>             Fix For: 3.5.0
>
>         Attachments: ZK1983.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.2#6252)

Reply via email to