Even then, the HISTCONTROL variable has to be set before running the command you don't want showing in history.  Also, contrary to what I keep reading from Google results, this variable doesn't seem to be automatically set, or at least not on the various Linux distros I've used. ... View more

I too, was seeing a similar message, with the GUID and IP of the UF that was supposedly having an issue.  Accompanying that, I was getting an email from an alert I'd set up for "UFs no longer sending logs", and my monitoring console also showed it was missing. However, if I did a query for it on a search head, I was definitely still seeing current events coming in, and my deployment server said it was still checking in. This is in a mixed environment of the architectural Splunk components (MC, CM, DSLM, SHs, HFs, IDXs) running on Linux, and the majority if UFs running on Windows.  Due to my department, I do not have OS access to those Windows servers. As an experiment, I created a simple text file on the DS, set it to restart Splunkd, added it to new server class, and assigned only the problem UF client to it.  As expected, once the client got the file, the UF restarted and the symptoms went away. @PickleRickWould removing the tracker.log have solved the issue as well?  I had the admin, who had OS access to it, restart the UF, but it did not solve the issue.  Maybe him just restarting the UF wouldn't have been enough and would have just come back up using the same tracker.log? ... View more

Correction... it doesn't seem to have anything to do with the upgrade but rather the use of (/opt/splunk/bin/splunk start|stop).  If either of these commands are issued, whatever Splunkd.service file exists is renamed and replaced with a new one. ... View more

I was running version 8.1.4 and upgraded to 8.20.  Before the upgrade I had no messages other than that there was a new version available.  After the upgrade I now get the message: Missing or malformed messages.conf stanza for INSTALLED_FILES_INTEGRITY:FOUND_INTEGRITY_PROBLEMS__889_server.domain.com The "889" is newer.  It started out as "9".  I compared the referenced messages.conf file to one I had on a  test instance running version 8.1.2, specifically the referenced stanza, and they looked to be identical.  I see this thread has been open for quite a long time and hasn't been answered, and the problem seems to have affected older versions.  I guess I might have to ask some of the Splunk engineers in my professional capacity. ... View more

I didn't resolve it.  It's still there, but my install has not stopped working either. ... View more

I'm getting something similar, but not quite the same: This pool contains slave(s) with 0 warning(s) I have only one instance of Splunk running, there are no slaves.  It's installed on my syslog server.  I hadn't noticed this message until today, after I changed my trial license to the free one.  Is this something I should be addressing? ... View more

I spent too much of a day trying to figure out why 2 of 5 servers were not showing up in my Indexer. I tried removing then adding the forward-server information, restarting the forwarder over and over and even reinstalling the forwarder on each, but they just didn't show up. Using telnet I confirmed the connection was open and the Indexer was listening. In the forwarders' splunkd.log files I confirmed the connection was being made. Finally I happened to change my search string to "index=_internal host=*" and there they were, but there was only one source from each and it was $SPLUNK_HOME/var/log/splunk/splunkd.log. The other 3 servers that were working had many more sources. A little bit more searching and I found this command: $SPLUNK_HOME/bin/splunk list monitor Sure enough, only splunkd.log was being forwarded. So I ran: $SPLUNK_HOME/bin/splunk add monitor /var/log This was what the "working" servers showed in their "list monitor" results. When running "host=*" in the search app, there were the 2 servers that wouldn't work before. ... View more