
When to restart Splunk Enterprise after a configuration file change
When you make changes to Splunk Enterprise using the configuration files, you might need to restart Splunk Enterprise for the changes to take effect.
Note: Changes made in Splunk Web are less likely to require restarts. This is because Splunk Web automatically updates the underlying configuration file(s) and notifies the running Splunk instance (splunkd) of the changes.
This topic provides guidelines to help you determine whether to restart after a change. Whether a change requires a restart depends on a number of factors, and this topic does not provide a definitive authority. Always check the configuration file or its reference topic to see whether a particular change requires a restart. For a full list of configuration files and an overview of the area each file covers, see List of configuration files in this manual.
When to restart forwarders
If you make a configuration file change to a heavy forwarder, you must restart the forwarder, but you do not need to restart the receiving indexer. If the changes are part of a deployed app already configured to restart after changes, then the forwarder restarts automatically.
When to restart splunkweb
You must restart the splunkweb process to enable or disable SSL for Splunk Web access.
When to restart splunkd
As a general rule, restart splunkd after modifying the following:
- settings and properties that affect indexers and indexing behavior
- settings and properties that affect users and roles
- settings and properties that affect Splunk's core configuration
Index changes
Note: When settings that affect indexing are changed through Splunk Web and the CLI, they do not require restarts and take place immediately.
- Index time field extractions
- Time stamp properties
User and role changes
Any user and role changes made in configuration files require a restart, including:
- LDAP configurations (If you make these changes in Splunk Web you can reload the changes without restarting.)
- Password changes
- Changes to role capabilities
- Splunk Enterprise native authentication changes, such as user-to-role mappings.
System changes
Changes that affect the system settings or server state require restart.
- Licensing changes
- Web server configuration updates
- Changes to general indexer settings (minimum free disk space, default server name, etc.)
- Changes to General Settings (eg., port settings)
- Changing a forwarder's output settings
- Changing the timezone in the OS of a splunk server (Splunk Enterprise retrieves its local timezone from the underlying OS at startup)
- Creating a pool of search heads
- Installing some apps may require a restart. Consult the documentation for each app you are installing.
Splunk Enterprise changes that do not require a restart
Settings that apply to search-time processing take effect immediately and do not require a restart. This is because searches run in a separate process that reloads configurations. For example, lookup tables, tags, and event types are re-read for each search.
This includes (but is not limited to) changes to:
- Lookup tables
- Field extractions
- Knowledge objects
- Tags
- Event types
Files that contain search-time operations include (but are not limited to):
macros.conf
props.conf
Changes to search-time field extractions are re-read at search timetransforms.conf
savedsearches.conf
(If a change creates an endpoint you must restart.)
To view your endpoints type the following into your browser:
How to reload files
To reload transforms.conf
:
http://yoursplunkserver:8000/en-us/debug/refresh?entity=admin/transforms-lookup for new lookup file definitions that reside within transforms.conf http://yoursplunkserver:8000/en-us/debug/refresh?entity=admin/transforms-extract for new field transforms/extractions that reside within transforms.conf
To reload authentication.conf
, use Splunk Web. Go to Settings > Access controls > Authentication method and click the Reload authentication configuration button. This refreshes the authentication caches, but does not disconnect current users.
Restart an indexer cluster
To learn about restarts in an indexer cluster, and when and how to use a rolling restart, see When and how to restart clusters in Managing Indexers and Clusters of Indexers.
Use cases
In complex situations, restarting Splunk Enterprise is the safest practice. Here are a few examples of scenarios where you might (or might not) be able to avoid a restart.
Scenario: You edit search- or index-time transforms in props.conf
and transforms.conf
Whether to restart depends on if the change is related to a index-time setting or a search-time setting. Index-time settings include:
- line breaking
- timestamp parsing
Search-time settings relate mainly to field extraction and creation and do not require a restart. Any index-time changes still require a restart. So for example:
1. If props.conf
and tranforms.conf
are configured as search-time transforms on the index, you don't have to do anything. For any search-time changes, each time you run a search Splunk reloads the props.conf
and transforms.conf
.
2. If the search-time changes are on a heavy forwarder, you must restart that forwarder. (If the changes are part of a deployed app configured to restart after changes, then this would happen automatically.)
3. If it is an index-time transform on the indexer you must restart the indexer to add the changes.
Scenario: You edit savedsearches.conf
and the new search creates a REST endpoint
You must restart the indexer to integrate the new endpoint.
Scenario: You build or modify an app or add-on
If you build an app or add-on that affects transforms.conf
, props.conf
, or lookups, you must restart Splunk Enterprise before creating a search in Splunk Web with the new changes.
PREVIOUS How to edit a configuration file |
NEXT List of configuration files |
This documentation applies to the following versions of Splunk® Enterprise: 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
Feedback submitted, thanks!