# Filebeats Kubernetes File close due to inactive of 5min
**URL:** https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855
**Category:** Beats
**Tags:** filebeat
**Created:** [March 24, 2020, 2:00pm UTC](https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855 "2020-03-24T14:00:11Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@ConorTier](https://discuss.elastic.co/u/ConorTier)
#### Post date: [March 24, 2020, 2:00pm UTC](https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855/1 "2020-03-24T14:00:11Z")
Hey,
Here is the setup currently have half working - Kubernetes - Amazon K8 - with a instance of logstash and file beats running on two pods - no demon sets for filebeats as want to read files from a specific directory on each of the pods (logs are stored in a volume mounted persistent volume- specifically azure file storage) - not interested in the pods docker stout. Also persistent volume to hold data from log files delta ids for redeployments as not to loose filebeats data deltas for files.
Currently filebeats is running and send the logs to logstash over a given port - can view these inputs in logshash logs. **Issue is when the file becomes inactive after 5 minutes and new entries are not read**. I have to redeploy in order to read the file again from last delta.
I see other threads and posts on this - stating to increase the timeout from 5min - this is not a solution. - **When file is written to filebeats is simply not reading the new input**. (be it 5min or 6 month timout - if microservice is called once every year even I should be entitles to read that new microservices log file via the filebeat)
Others saying that this issue is resolved after version 5.0 filebeats. Im using filebeats version:
[docker.elastic.co/beats/filebeat:7.6.1](http://docker.elastic.co/beats/filebeat:7.6.1)
Using Azure Kubernetes version 1.17.3
Any ideas as to why filebeats is not reading new input after a file becomes inactive (file should become active again)?
Thanks
---
### Author:  [@ConorTier](https://discuss.elastic.co/u/ConorTier)
#### Post date: [March 24, 2020, 3:40pm UTC](https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855/2 "2020-03-24T15:40:20Z")
Little more background in case it helps - Microservices created in .net core - using log4net logging - file appender - this should not matter as its just creating a something.log file with a specific format for each log output.
Havent changed the scan\_frequency - default is 10 seconds and close\_inactive is still at its default - (5 mintues)
In theory once a log entry is entered every 10 minutes as example - it should appear to filebeat output every 10 minutes and 10 seconds - note logs dont come in every 10 minutes - just an example.
---
### Author:  [@ConorTier](https://discuss.elastic.co/u/ConorTier)
#### Post date: [March 25, 2020, 8:43am UTC](https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855/3 "2020-03-25T08:43:20Z")
Extra info - in filebeat if I enable debug logging I can see the scan interval checking the file(s) in question
2020-03-25T08:39:33.230Z DEBUG [input] log/input.go:421 Check file for harvesting: /usr/share/filebeat/mslogshare/logging.log
2020-03-25T08:39:33.230Z DEBUG [input] log/input.go:511 Update existing file for harvesting: /usr/share/filebeat/mslogshare/logging.log, offset: 939
2020-03-25T08:39:33.230Z DEBUG [input] log/input.go:565 File didn't change: /usr/share/filebeat/mslogshare/logging.log
Offset of 939 but if I open the actual file logging.log I can see extra entries after char position 939 - not filtered out or anything - data after 939 is in same format as before 939
Im at a loss
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [April 22, 2020, 8:43am UTC](https://discuss.elastic.co/t/filebeats-kubernetes-file-close-due-to-inactive-of-5min/224855/4 "2020-04-22T08:43:36Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.