# Filebeat holding open handles on deleted files
**URL:** https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192
**Category:** Beats
**Tags:** filebeat
**Created:** [September 2, 2021, 3:36pm UTC](https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192 "2021-09-02T15:36:29Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@seadub](https://discuss.elastic.co/u/seadub)
#### Post date: [September 2, 2021, 3:36pm UTC](https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192/1 "2021-09-02T15:36:29Z")
v. 6.8.4
We are experiencing issues daily with lingering open file handles on files which have been deleted by another process which has completed daily compression of logs.
The files seem to remain open forever until we manually restart the filebeat process.
Config example here:
```auto
- type: log
enabled: true
paths:
- /logs//**/*.json.log
fields:
format: json
...more custom fields...
```
[From the docs](https://www.elastic.co/guide/en/beats/filebeat/6.8/filebeat-input-log.html#filebeat-input-log-close-inactive), `close_inactive` doesn't get included by default, but then it kinda does? I'm having a hard time confirming that.
> When this option is enabled...
> ...The default is 5m.
If a file was "deleted" but then has no activity on it after being deleted, the handle should be closed if that "close\_inactive" was defaulted to true. That deleted file should really have been deleted then, and the harvester should have no longer been able to find it....
I'm looking for confirmation on the behavior of the process when `close_inactive` is not set at all for any of the inputs.
---
### Author:  [@kvch](https://discuss.elastic.co/u/kvch)
#### Post date: [September 3, 2021, 2:12pm UTC](https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192/2 "2021-09-03T14:12:56Z")
`close_inactive` is enabled by default. However, it does not work as expected in 6.8.
Filebeat usually keeps files open if there is backpressure in the output, e.g. Elasticsearch is not able to process incoming events. Are there any issues in your output causing the Beat keeping files open?
The behaviour of this option has been fixed in Filebeat 7.x. Also, we have come up with a new input for log files called filestream: [filestream input | Filebeat Reference [7.14] | Elastic](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-filestream.html) It has much better support for closing files in time even if there is backpressure in the system. Please consider switching versions and inputs.
---
### Author:  [@seadub](https://discuss.elastic.co/u/seadub)
#### Post date: [September 3, 2021, 3:39pm UTC](https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192/3 "2021-09-03T15:39:06Z")
Hi Noémi - Thanks for the confirmation.
The output is set to logstash. We're pretty sure there is back pressure there, but are having a tough time confirming due to lack of visibility. The metrics available for filebeat are showing no errors/retries occurring, and logstash metrics/logs aren't showing anything about rejecting requests either.
Can you provide more details on "it does not work as expected in 6.8" ?
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [October 1, 2021, 5:39pm UTC](https://discuss.elastic.co/t/filebeat-holding-open-handles-on-deleted-files/283192/4 "2021-10-01T17:39:43Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.