When I try to start Splunk it gives the following output -
Splunk> CSI: Logfiles. Checking prerequisites... Checking http port : open Checking mgmt port : open Checking configuration... Done. Checking index directory... Done. Checking databases... ERROR :: 'homePath' An error occurred: Could not validate indexes, will not continue (returned 1).
What does this error mean? Why wont my Splunk start?
This means that Splunk has a problem figuring out where the
homePath of one of your indexes lives. Usually it's the result of copying & pasting index settings and forgetting to update the
homePath for a new directory, so you end up with 2 indexes with the same path.
Alternatively, it can be the result of not defining an index correctly when editing an
indexes.conf file by hand. You may have a typo in the setting, or you may have forgotten it entirely.
One common fault we find is that an index is created in one app - for example the
os index in the Unix app - and somehow modified in
$SPLUNK_HOME/et/system/local/indexes.conf. If the Unix app then disabled later on for some reason, the next time Splunk starts up, it will see the entry in the
.../local/indexes.conf file, but won't see the original entry in
$SPLUNK_HOME/etc/apps/unix/default/indexes.conf, because it has been disabled. As far as Splunk is concerned, it's being told to apply a setting to an index, but it doesn't know where that index lives.
I ran into that very scenario this morning. Removed the [os] block from my $SPLUNK_HOME/etc/local/indexes.conf and recovered right away.
I just ran into it. This is what did it for me: http://www.splunk.com/base/Documentation/4.1.4/ReleaseNotes/KnownIssues
On the first startup after upgrading, you see the message - Checking databases... ERROR :: 'homePath' - In the 4.1.4 build, we removed an old legacy index called [splunklogger] from the $SPLUNK_HOME/etc/system/default/indexes.conf, if you have a reference to this index in any of their other indexes.conf files, it will cause this error and not allow Splunk to startup. Remove that entry, and Splunk will start.
During the first start up after the upgrade, Splunk tries to validate the existence of all declared indexes in the indexes.conf found in your configuration directories.
Even if an index is disabled with "disabled = true" or by being present in the indexes.conf of a disabled app, Splunk will freak out if it cannot locate it's "homePath" (whether it's the default one in $SPLUNK_DB or a custom one specified in indexes.conf).
The quickest way to troubleshoot this problem is to compare the output of two commands.
The first one displays all existing index configuration stanzas across all indexes.conf :
# find $SPLUNK_HOME/etc/ -name indexes.conf | xargs grep ^\\[
The second command will list the directories present in $SPLUNK_DB ($SPLUNK_HOME/var/lib/splunk/ by default), which is the default "homePath" for each index if no other value for that parameter is specified.
# ls -l $SPLUNK_DB
# ls -l $SPLUNK_HOME/var/lib/splunk/
If the first command shows an index that is not present in $SPLUNK_DB and that index doesn't have a setting for "homePath" that points to an existing directory, you should consider disabling that index stanza in that configuration file by preceding it with a "#".
Typical culprits are "splunklogger" (which has been deprecated and is often present but disabled) and "os" (which is often present in disabled apps like "unix" or "nixLF").
This is particularly effective on a forwarder where there shouldn't be any indexes configured other than what can be found in $SPLUNK_DB.
Here's a typical scenario :
1) Which index directories exist?
# ls -l $SPLUNK_DB total 52 drwx--x--x 5 root root 4096 Jun 25 16:29 audit drwx--x--x 2 root root 4096 Jun 25 10:14 authDb drwx--x--x 5 root root 4096 Jun 25 16:29 blockSignature drwx--x--x 5 root root 4096 Jun 25 16:29 defaultdb drwx--x--x 6 root root 4096 Jun 25 16:29 fishbucket drwx--x--x 2 root root 4096 Jun 25 16:29 hashDb drwx--x--x 5 root root 4096 Jun 25 16:29 historydb drwx--x--x 5 root root 4096 Jun 25 16:29 _internaldb drwx------ 2 root root 4096 Jun 25 16:29 persistentstorage drwx------ 2 root root 4096 Jun 25 16:27 queues drwx--x--x 5 root root 4096 Jun 25 16:29 sample drwx--x--x 5 root root 4096 Jun 25 16:29 splunkloggerdb drwx--x--x 5 root root 4096 Jun 25 16:29 summarydb
2) Which indexes are declared in the configuration files?
# find $SPLUNK_HOME/etc/ -name indexes.conf | xargs grep ^\\[ etc/system/default/indexes.conf:[main] etc/system/default/indexes.conf:[history] etc/system/default/indexes.conf:[summary] etc/system/default/indexes.conf:[_internal] etc/system/default/indexes.conf:[_audit] etc/system/default/indexes.conf:[_thefishbucket] etc/system/default/indexes.conf:[_blocksignature] etc/system/default/indexes.conf:[splunklogger] etc/apps/sample_app/default/indexes.conf:[sample] etc/apps/nixLF/default/indexes.conf:[main] etc/apps/nixLF/default/indexes.conf:[history] etc/apps/nixLF/default/indexes.conf:[summary] etc/apps/nixLF/default/indexes.conf:[_internal] etc/apps/nixLF/default/indexes.conf:[_audit] etc/apps/nixLF/default/indexes.conf:[_blocksignature] etc/apps/nixLF/default/indexes.conf:[splunklogger] etc/apps/unix/default/indexes.conf:[os] etc/apps/SplunkLightForwarder/default/indexes.conf:[main] etc/apps/SplunkLightForwarder/default/indexes.conf:[history] etc/apps/SplunkLightForwarder/default/indexes.conf:[summary] etc/apps/SplunkLightForwarder/default/indexes.conf:[_internal] etc/apps/SplunkLightForwarder/default/indexes.conf:[_audit] etc/apps/SplunkLightForwarder/default/indexes.conf:[_blocksignature] etc/apps/SplunkLightForwarder/default/indexes.conf:[splunklogger]
This revealed the following culprits :
etc/apps/unix/default/indexes.conf:[os] etc/system/default/indexes.conf:[splunklogger] etc/apps/nixLF/default/indexes.conf:[splunklogger] etc/apps/SplunkLightForwarder/default/indexes.conf:[splunklogger]
The "splunklogger" index was disabled everywhere it was declared with "disabled = true", and the "os" index was not in use as the unix app was disabled. Once these stanzas and all of their associated parameters were commented out, the upgrade worked!