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 http://www.splunk.com/page/submit_issue 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
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.