couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Hirst (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1129) file descriptors sometimes not closed after compaction
Date Wed, 28 Mar 2012 07:30:35 GMT


Paul Hirst commented on COUCHDB-1129:

This has just happened to me on 1.1.1 for the very first time. A compaction process left the
old database file handle open (the file had been moved to .delete and deleted according to
lsof). The compaction had finished 11 hours prior to me noticing I hadn't got the disk space
back so a fair amount of time had passed. There weren't any long running view updates occuring.
The database is under fairly continuous write load from processes using keep-alive HTTP connections.
Would this be the problem?

This is the first time I've seen this in probably 20 or 30 compactions on 1.1.1 so I doubt
I can replicate it.

I called _restart, the couch service stopped responding to requests for a few seconds (probably
while the file was removed, certainly longer than normal restarts) and then everything was
fine. There are no errors in the log. Infact I have logging set to 'error' and there is nothing
in the log at all.
> file descriptors sometimes not closed after compaction
> ------------------------------------------------------
>                 Key: COUCHDB-1129
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 1.0.2
>            Reporter: Randall Leeds
>             Fix For: 1.1.1, 1.2
> It seems there are still cases where file descriptors are not released upon compaction
> When I asked on IRC rnewson confirmed he'd seen the behavior also and the last comment
on 926 also suggests there are still times where this occurs.
> Someone needs to take a careful eye to any race conditions we might have between opening
the file and subscribing to the compaction notification.

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