topic Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza? in Getting Data In

Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

joeyblasko — Thu, 15 Sep 2016 18:29:42 GMT

I setup my universal forwarder to monitor a folder and send the contents to one of my indexers. That works great. I changed the inputs.conf from the monitor stanza to the batch stanza and added the property move_policy=sinkhole. I expected that the files in the folder would be deleted after they are sent to the indexer. This is not happening. The documentation indicates that this should be the case. Does the Universal Forwarder support the batch stanza?

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

jtacy — Thu, 15 Sep 2016 20:40:31 GMT

Yes, the UF supports the batch stanza and it should be deleting the files. Can you share the full batch stanza that you're using? Is this on Windows or Linux? I'm thinking that on Windows the files might be locked by whatever is generating them; I imagine something like Process Monitor could be used to determine if that's happening. Other than that, if the UF isn't running as root on Linux or Local System on Windows, I would consider checking file system permissions to verify that the UF has rights to delete. In either of those cases you might see a line in splunkd.log that looks like:

09-15-2016 15:37:01.318 -0500 ERROR TailReader - Unable to remove sinkhole file: path=/opt/splunk/app/xyzzy/xyzzy.log, errno=Permission denied

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

MuS — Thu, 15 Sep 2016 20:53:48 GMT

Just one little addition: the UF will only remove new files since the inputs.conf was changed, because the other older files were already indexed and therefore ignored by the UF.

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

jtacy — Thu, 15 Sep 2016 21:37:07 GMT

Interesting! The behavior I'm seeing on 6.4.0 is that when the stanza is changed to a batch and the UF restarted, files that match the target path are indexed again and deleted.

The monitor stanza that I tested looks like:
[monitor:///opt/splunk/app/monitorswap2/*.log]
sourcetype = xyzzy
index = main

...and the batch stanza looks like:
[batch:///opt/splunk/app/monitorswap2/*.log]
sourcetype = xyzzy
index = main
move_policy = sinkhole

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

joeyblasko — Mon, 19 Sep 2016 14:18:38 GMT

I am on linux CentOS 7. Here is the stanza:

[monitor:///data/test]
disabled = 0
index = test
sourcetype = testJson
crcSalt = 
_TCP_ROUTING = test_dev

[batch:///data/test]
move_policy = sinkhole
disabled = 0
index = test
sourcetype = testJson
crcSalt = 
_TCP_ROUTING = test_dev

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

joeyblasko — Mon, 19 Sep 2016 14:20:05 GMT

The crcSalt stanza is set to the SOURCE value but when I posted it was removed. It is correct in my conf file.

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

jtacy — Mon, 19 Sep 2016 16:33:53 GMT

You don't have the monitor and batch stanzas in place at the same time, correct? The files won't be deleted if you have monitor and batch stanzas watching the same path. If you only have a batch stanza and the files still aren't being deleted I'd suspect that the UF doesn't have the required permissions.

Re: Why are files in a folder not getting deleted on the universal forwarder with move_policy=sinkhole in the inputs.conf batch stanza?

joeyblasko — Mon, 19 Sep 2016 18:10:09 GMT

I do not have them in the conf file at the same time. I will look at the permissions.