ksconf check

Provides basic syntax and sanity checking for Splunk’s .conf files. Use Splunk’s built-in btool check for a more robust validation of attributes and values.

Consider using this utility as part of a pre-commit hook.

usage: ksconf check [-h] [--quiet] FILE [FILE ...]

Positional Arguments


One or more configuration files to check. If ‘-’ is given, then read a list of files to validate from standard input

Named Arguments

--quiet, -q

Reduce the volume of output.

See also

Pre-commit hooks

See Pre-commit hooks for more information about how the check command can be easily integrated in your git workflow.

How ‘check’ differs from btool’s validation

Keep in mind that idea of valid in ksconf is different than within Splunk. Specifically,

  • Ksconf is more picky syntactically. Dangling stanzas and junk lines are picked up by ksconf in general (the ‘check’ command or others), but silently by ignored Splunk.

  • Btool handles content validation. The btool check mode does a great job of checking stanza names, attribute names, and values. Btool does this well and ksconf tries to not repeat things that Splunk already does well.

Why is this important?

Can you spot the error in this props.conf?

4category = Web
5REPORT-access = access-extractions
8TRANSFORMS-drop = drop-all

That’s right, line 7 contains the stanza myapp:total:junk that doesn’t have a closing ]. How does Splunk handle this? It ignores the broken stanza header completely and therefore TRANSFORMS-drop gets added to the myapp:web:access sourcetype, which will likely result in the loss of data.

Splunk also ignores entries like this:


Of course here there’s no = anywhere on the line, so Splunk just assumes it’s junk and silently ignores it.


If you want to see how different this is, run ksconf check against the system default files:

ksconf check --quiet $SPLUNK_HOME/etc/system/default/*.conf

There’s several files that ship with the core product that don’t pass this level of validation.