Filebeat holds on to a file descriptor too long

[filebeater]

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?

Hello, filebeat experts, I reported a similar problem before in Filebeat might erroneously hold on to the file descriptor? 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

[filebeater]

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