Splunk® Enterprise

Troubleshooting Manual

Download manual as PDF

Download topic as PDF

Splunk Enterprise does not start due to unusable filesystem

If you receive an error message like the following when you start Splunk Enterprise on a *nix machine, it might be because the software does not know how to write to your machine filesystem.

homePath='/opt/splunk/var/lib/splunk/audit/db' of index=_audit on unusable filesystem. Validating databases (splunkd validatedb) failed with code '1'.

Splunk Enterprise must be able to write to the local filesystem to index your data. Splunk provides support for many different filesystems, as described in System requirements in the Installation Manual. On machines with an unrecognized filesystem, Splunk Enterprise runs a utility called locktest that confirms whether it can work with the filesystem. If locktest fails for any reason, splunkd does not start, to prevent you from indexing data to a filesystem that it cannot write to.

The locktest utility can fail for a number of reasons:

  • The filesystem is not known, and Splunk Enterprise cannot perform the proper file locking on it.
  • The filesystem has been marked as read-only, or has otherwise been changed by the operating system.
  • A library or function that locktest uses to perform the tests is not available or cannot be loaded.

This troubleshooting topic does not apply to Splunk Enterprise instances that run on Windows machines.

Temporarily bypass filesystem checks

If you are a Splunk administrator who understands the risks, you can temporarily bypass filesystem checks to get Splunk Enterprise running again.

Configuring this setting can be dangerous and is not supported in normal operations. Irrevocable data loss can occur. You perform this action solely at your own risk. By configuring the setting, you actively bypass filesystem checks that confirm if Splunk Enterprise can run on your machine filesystem. In a production environment, you must not use this setting as a long-term solution to a filesystem problem. If you use the setting under the guidance of Splunk Support, immediately report any problems that you encounter with indexing or search.

Use the setting in one or more of the following scenarios only:

  • You are a skilled Splunk administrator and understand the risks of bypassing filesystem checks.
  • You use Splunk software in a development environment.
  • You want to recover from a situation where the default filesystem has been changed outside of your control, such as during an operating system upgrade.
  • You want to recover from a situation where a Splunk bug has invalidated a previously functional filesystem after an upgrade.
  • You want to evaluate the performance of a filesystem for which Splunk has not yet offered support.
  • You have been given explicit instruction from Splunk Support to use the setting to solve a problem where Splunk software does not start because of a failed filesystem check.
  • You understand and accept all of the risks of using the setting, up to and including losing all your data with no ability to recover it.
  1. On the machine that is experiencing the failure, open a shell prompt.
  2. Become root or an administrative equivalent with su:
    sudo su -
    
  3. Open $SPLUNK_HOME/etc/splunk-launch.conf with a text editor.

    $SPLUNK_HOME represents where you have installed Splunk Enterprise. For example, if you installed Splunk Enterprise in /opt/splunk, then you would edit /opt/splunk/etc/splunk-launch.conf.

  4. In the file, add the following line anywhere:
    OPTIMISTIC_ABOUT_FILE_LOCKING=1
    
  5. Save the file and close the text editor.
  6. Restart Splunk Enterprise.
  7. Confirm that the splunkd service has started.
PREVIOUS
I get errors about ulimit in splunkd.log
  NEXT
HTTP thread limit issues

This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.3.0, 7.3.1, 7.3.2


Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters