As of today on a CentOS 6 server we tested to modify the shell for splunk user from /bin/bash to /sbin/nologin On this server it is running the Splunk Universal Forwarder. After having modified the /etc/passwd file and restarted the Splunk Universal Forwarder it is still working, as well as the scripts directly launched by it. #to modify the shell usermod -s /sbin/nologin splunk #to restart the Universal Forwarder /etc/init.d/splunk restart   ... View more

Indeed, looks like an issue with reports. I inserted the full search query into a dashboard panel, gave it full visibility and it finally worked. I tested with three different users. Solved. ... View more

had the same issue with splunk 6.5.3 in my case the problem was the firefox extension priv3+ ... View more

Hi, I know that this is the old question, but it would have saved my day if it was answered before ) The answer is to add time_before_close=60 (or another integer) into inputs.conf and all events will index correctly! https://answers.splunk.com/answers/103132/events-are-broken-in-the-middle-of-the-line.html https://answers.splunk.com/answers/492950/the-app-is-indexing-event-before-the-tmg-has-write.html ... View more

There is a slight modification. Instead of coalesce when it is |eval TempID = if(isnull(RefCoreID),CoreID,RefCoreID)|transaction TempID it works fine..Thanks for the idea anyways... ... View more

The easiest solution is to leverage the Prelert Anomaly Detective App. You can easily determine which ClientIP are making an abnormally different number of requests than other ClientIPs: index=accesslog | prelertautodetect count over ClientIP If you want to segment it by host as well: index=accesslog | prelertautodetect count by Hostname over ClientIP Here's a slightly different example of finding a ClientIP requesting a abnormally different number of pages than other ClientIPs, but in this case, segmented by status code: http://www.prelert.com/images/screenshots/count_by_status_over_clientip.png This is also be easily run on-going as a regularly scheduled search, so that you can continuously run it every X minutes. ... View more

coalesce is the way to go. If you have the proper sourcetype, you may have queued_as field, so "| eval matching_id=coalesce(queued_as,queueid) |" will do and you can drop the previous "rex". Be aware that you may get the same queue_id value on both servers within the maxspan timeframe, so consider differentiating your transactions adding the host field too: "| transaction queue_id, host ..." Splunk can tame the "Postfix logs" beast! 🙂 ... View more

THAT'S IT! Nested subsearch with a clever trick. I only needed to add double quotes to the eval: ... eval to="$to" ... otherwise it complains of the @ symbol. ... View more