Getting Data In

Why would splunk universal forwarder report "ERROR TailReader - File will not be read, is too small to match seekptr checksum" on a file whose events begin with a timestamp?

Path Finder

splunkd.log is reporting

ERROR TailReader - File will not be read, is too small to match seekptr checksum (file=/apps/xxx/xxx/xxx/xxx/logs/systemOut-1.log).  Last time we saw this initcrc, filename was different.  You may wish to use larger initCrcLen for this sourcetype, or a CRC salt on this source.  Consult the documentation or file a support case online at for more info

when re-starting the Universal forwarder on client servers.

The events logged in these systemOut files begin with date/timestamps:

[6/7/17 15:48:32:071 EDT] 00000288 SystemOut     O No Response View Handler
[6/7/17 15:48:40:424 EDT] 0000031d SystemOut     O Request On

and they roll to a dated filename (i.e. systemOut-1_17.06.07_11.02.26.log) when they reach about 1MB in size.

Why would splunk ever think it's seen these before when each event is unique within the first 25 bytes?

On these same servers the splunk u-forwarder monitors the systemErr files (which also start with date/time and share the same "roll" behavior as the systemOut files) and it does not report the same error for the systemErr files.

The only parameters used for each monitor stanza in inputs.conf are the host, index, and sourcetype

0 Karma

Path Finder

kbcall - I never did get an answer on this forum, but it turns out that after an upgrade to the middleware the systemOut files now had a header (and a rather lengthy one) written at the beginning of each file when it rolled over. So, we had to add the following parameter to the monitor stanza for these files in inputs.conf:

initCrcLength = 2000

Now Splunk ignores the 1st 2000 bytes/chars of the "new" file before determining if the content is "different".


Did you ever get an answer to this issue? It appears to be happening at our company as well.

0 Karma