We are trying to monitor a lot of systems that have various configurations of drives, (C:disk 😧 cdrom, c:disk d: disk e: disk f: cdrom, etc). The issue we are seeing is that with the below inputs.conf we are getting millions of "device not ready" messages in _internal index when splunk tries to look at the CDrom drive. Is there any way to force splunk not to check the CD drive If we don't know what drive the CD is? (I can't change the drive letter of the CDrom, and I can't change what drive the data is on).. so somtiems d: is a hard drive, sometimes 😧 is a CDrom (and we get the errors). This is a problem with both monitor & batch.
12-21-2012 18:06:25.979 +0100 WARN FilesystemChangeWatcher - error getting attributes of path "d:\splunk_logs\application": The device is not ready.
[batch://d:\splunk_logs\applicaton\*.txt|*.csv] move_policy = sinkhole disabled = false [batch://e:\splunk_logs\application\*.txt|*.csv] move_policy = sinkhole disabled = false
I need an answer to the same question. I need to monitor a CD drive and it successfully logs file changes in the local splunkd.log, but fails at sending them to the indexer because of a "Error getting attributes of path D:\somefolder\somefilename.ext". Can I prevent the change checker from trying to access the "attributes" of the drive? I don't need those; just file names.
Hey did anyone ever figure this out? I have the same problem and just posted.
I thought I could add a props and transforms to splunkd sourcetype for just that one host. But that did not work.
For what it's worth, I would never purposely downvote an answer like this. Apparently I downvoted in the past and I can't change my vote after a day... but the vote was by mistake if at all.
are the errors happening when the CDROM is in the drive when splunk starts ?
when you start splunk it will scan all locations you asked him to monitor.
So if you CDROM drive 😧 does not exist at the time you can expect warning messages.
also using move_policy = sinkhole for a READ-only device is probably not necessary.
I'd write a powershell script to determine what drive letter is a cdrom and change the inputs.conf accordingly.
http://techibee.com/powershell/find-drive-letter-of-cd-drive-using-powershell/1977 <- find the drive leter
http://stackoverflow.com/questions/17144355/string-replace-file-content-with-powershell <- string replace items in config file.
You can even run it as a scripted input, and add it to an application you deploy to all forwarders. So that it deploys with place holders in the config file, and then your powershell script executes to 1. change the inputs.config file to appropriately monitor only non-CDROM drives. 2. change the scripted input schedule to disable the powershell after it's first successful run.
I am now running into this as well. Any better solution than turning off Warning messages or NullQueuing these logs?
This needlessly increases the amount of apps needed on a Deployment Server since different servers here have the same files on different drive letters.
Did you ever hear anything back? I've revisited this numerous times, and we're about to go with @jkat54 's solution (custom one-time PowerShell input to update