The base behavior here is fundamental Unix. When any process calls the unlink() system call to remove a file, the blocks allocated to the file remain allocated until all processes that have the file open have closed it. Typically this is not a big problem for Splunk as Splunk tends to open files for a very short window (a few seconds) and then close them when there is a brief window of idleness detected on the file. This idleness window is controlled by the TIME_BEFORE_CLOSE option in inputs.conf. Splunk can keep a file open for a very long time in a few edge cases: If the TIME_BEFORE_CLOSE setting is set incredibly high for the file in question If the file is active enough that it never has any "quiet time" If the file has a large amount of data that needs to be processed, and it has been kicked over to a BatchReader thread in response Usually, I would say that the BatchReader issue is most likely the problem in this case. There are a couple of things to tune to help with this, like maxKBps in limits.conf (to allow the forwarder to output more data at once to the indexers), and parallelPipelineCount in server.conf (to allow more threads to process data in parallel). I would expect that in most cases Splunk would fairly quickly (minutes) read to the end of the deleted file, and then close it. At which time, the kernel would release all of the filesystem blocks allocated for the file. By stopping Splunk, you force it to close the file perhaps early, and probably caused some events to be lost. (Which may be something you don't care about) ... View more