# Filebeat holds on to a file descriptor too long

**URL:** https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long/125294
**Category:** Beats
**Tags:** filebeat
**Created:** [March 23, 2018, 2:11am UTC](https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long/125294 "2018-03-23T02:11:56Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![filebeater](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/filebeater/32/18565_2.png) [@filebeater](https://discuss.elastic.co/u/filebeater)
#### Post date: [March 23, 2018, 2:11am UTC](https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long/125294/1 "2018-03-23T02:11:56Z")

</div>

Hello, there,  
We finally upgrade filebeat from 5 to 6.1.3, however, the same problem still persists.

> [@Filebeat holds on to a file descriptor too long even after a file was deleted?](https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long-even-after-a-file-was-deleted/117731):
>
> Hello, filebeat experts, I reported a similar problem before in [Filebeat might erroneously hold on to the file descriptor?](https://discuss.elastic.co/t/filebeat-might-erroneously-hold-on-to-the-file-descriptor/104957) thanks @steffens for the tips! I added the following to our config file back then, which worked for us for a while. I did not have special settings for close-\* and clean\_\* options. since the default values for those settings make sense to us. close\_removed: true our disk space was filled up by log files today. Even after deleting log files, filebeat still holds on to …

(sorry I could not reply to the original thread since it is more than a month old.  
We observed the same issue today even after we upgraded filebeat to 6.1.3.

(1) filebeat still holds on to its file descriptor when it is more than an hour after a file being rotated.  
(since I have " close\_inactive: 10m" in the config, filebeat should close the fd 10 minutes after a log file being rotated?

(2) After a file being deleted, filebeat still holds on to its file descriptor  
I have **close\_removed: true** , so this should not happen?  
(Both observed from lsof)

Relevant filebeat config is:

# closes the harvester/fd when a file is removed.

close\_removed: true

# filebeat will focus on sending the current log files

ignore\_older: 36h  
close\_inactive: 10m

# set max lifetime of each harvester (fd)

close\_timeout: 30h  
clean\_inactive: 48h

---

<div class="post-metadata">

### Author: ![filebeater](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/filebeater/32/18565_2.png) [@filebeater](https://discuss.elastic.co/u/filebeater)
#### Post date: [March 23, 2018, 3:12am UTC](https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long/125294/2 "2018-03-23T03:12:23Z")

</div>

btw, should I be more aggressive in these config setting, hoping even if one mechanism fails, another will pick up the slack?  
e.g. , in addition to close\_inactive: 10m  
be more aggressive in the following?  
ignore\_older: 25h  
close\_timeout: 25h  
clean\_inactive: 25h

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [April 20, 2018, 3:12am UTC](https://discuss.elastic.co/t/filebeat-holds-on-to-a-file-descriptor-too-long/125294/3 "2018-04-20T03:12:23Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
