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

Shyamal Prasad commented on ZOOKEEPER-1983:
-------------------------------------------

Patrick, apologies for the newbie issues, and thanks for the pointers.

The reported build failure (for NioNettySuiteHammerTest) seems to be unrelated 
and afaict it's been failing for two weeks or so, (r1609730).

Regarding the missing updates for a test case: it's not obvious that it is 
valuable to add one. I did find src/java/test/bin/test-scripts.sh which might 
allow me to add a (somewhat convoluted) test to verify that we do not clobber 
an existing file on startup. I'm not sure if that is the policy for script 
updates; advice appreciated.

> 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.0
>
>         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.2#6252)

Reply via email to