couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (Updated) (JIRA)" <>
Subject [jira] [Updated] (COUCHDB-1380) logrotate doesn't work correctly with couchdb 1.2.x
Date Tue, 17 Jan 2012 10:06:40 GMT


Robert Newson updated COUCHDB-1380:

    Priority: Blocker  (was: Minor)

Possibly disk_log is keeping an internal track of its write position and doing a positioned
write (file:pwrite) call. After truncation by logrotate, this would cause a file hole on filesystems
that support it and would actually fill in all that space with zeroes on filesystems that
do not.

In any case, this should be fixed before the 1.2. release. Thanks for reporting it!
> logrotate doesn't work correctly with couchdb 1.2.x
> ---------------------------------------------------
>                 Key: COUCHDB-1380
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>    Affects Versions: 1.2
>         Environment: CentOS 5.6 x64, couchdb 1.2.x (13th Jan 2012 - 1.2.0a-08d8f89-git),
logrotate 3.7.4
>            Reporter: Alex Markham
>            Priority: Blocker
>              Labels: logging, logrotate
> Running logrotate -f with couchdb 1.2.x leaves null data at the start of the couch.log
file, I'm guessing equal to the size of data that should have been removed and rotated into
the log.1 (eg "head -c 1000000000 couch.log" is blank)
> This does not happen on couchdb 1.1.1, 1.0.2 or 1.0.3
> The log files then stay large, and when trying to grep or less them, they are reported
as binary.
> This seems to have happened to another user, but no details of OS or version were reported: 
> The logrotate config used is very similar to the one installed with couchdb -
> /var/log/couchdb/*.log {
>        size=150M
>        rotate 5
>        copytruncate
>        compress
>        delaycompress
>        notifempty
>        missingok
> }
> Has there been any changes to the interaction with log files/file handles since 1.1.1?
Does couchdb need to receive a SIGHUP? Or can anyone reproduce this?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message