Getting Data In

After upgrading Splunk from 6.3.0 to 6.4.1, why am I getting error "Invalid value in stanza [header_nullq]" on restart?



I upgraded Splunk from 6.3.0 to 6.4.1. On restarting Splunk, I am getting below messages.

Checking filesystem compatibility... Done
*Checking conf files for problems...
Invalid value in stanza [header_nullq] in /opt/splunk/etc/apps/CCMS-TA-onprem-reporting/default/transforms.conf, line 4: (key: DEST_KEY, value: nullqueue)

Your indexes and inputs configurations are not internally consistent. For more information, run 'splunk btool check --debug'
cannot find non-empty stack=download-trial for pool=auto_generated_pool_download-trial, skipping

// Content of my transforms.conf file

DEST_KEY = queue
REGEX = ^TimeStamp
FORMAT = nullqueue

Is it due to the upgrade? How to resolve this issue?
Can somebody please help here?


0 Karma

Splunk Employee
Splunk Employee

This is a new message added into splunk version 6.3.2+ for invalid values, especially invalid queue names - use nullQueue.
Backported to 6.2.7+, for further information please feel free to contact Splunk Support.

0 Karma

Ultra Champion

You probably should run splunk btool check --debug.

Similar thing at How do I resolve these errors during start up of splunk 6.2?

0 Karma


Tried this way as well.
Still same issue

Invalid value in stanza [eventtype=header_nullq] in /opt/splunk/etc/apps/CCMS-TA-onprem-reporting/default/transforms.conf, line 4: (key: DEST_KEY, value: nullqueue)

Content of transforms.conf file
DEST_KEY = queue
REGEX = ^TimeStamp
FORMAT = nullqueue

0 Karma


It's saying your FORMAT = nullqueue is not recognized as a good value. I believe you're hoping to send all events that match your regex to nullqueue,.. to do so you do this:

REGEX = ^TimeStamp
DEST_KEY = nullQueue

Format is not required in this use case.

This excerpt is from transforms.conf:

FORMAT = <string>
* NOTE: This option is valid for both index-time and search-time field extraction. However, FORMAT
  behaves differently depending on whether the extraction is performed at index time or
  search time.
* This attribute specifies the format of the event, including any field names or values you want
  to add.
* FORMAT for index-time extractions:
  * Use $n (for example $1, $2, etc) to specify the output of each REGEX
  * If REGEX does not have n groups, the matching fails.
  * The special identifier $0 represents what was in the DEST_KEY before the
    REGEX was performed.
  * At index time only, you can use FORMAT to create concatenated fields:
    * Example: FORMAT = ipaddress::$1.$2.$3.$4
  * When you create concatenated fields with FORMAT, "$" is the only special
    character. It is treated as a prefix for regex-capturing groups only if
    it is followed by a number and only if the number applies to an existing
    capturing group. So if REGEX has only one capturing group and its value
    is "bar", then:
      * "FORMAT = foo$1" yields "foobar"
      * "FORMAT = foo$bar" yields "foo$bar"
      * "FORMAT = foo$1234" yields "foo$1234"
      * "FORMAT = foo$1\$2" yields "foobar\$2"
  * At index-time, FORMAT defaults to <stanza-name>::$1
* FORMAT for search-time extractions:
  * The format of this field as used during search time extractions is as
    * FORMAT = <field-name>::<field-value>( <field-name>::<field-value>)*
      * field-name  = [<string>|$<extracting-group-number>]
      * field-value = [<string>|$<extracting-group-number>]
  * Search-time extraction examples:
      * 1. FORMAT = first::$1 second::$2 third::other-value
      * 2. FORMAT = $1::$2
  * If the key-name of a FORMAT setting is varying, for example $1 in the
    example 2 just above, then the regex will continue to match against the
    source key to extract as many matches as are present in the text.
  * NOTE: You cannot create concatenated fields with FORMAT at search time.
    That functionality is only available at index time.
  * At search-time, FORMAT defaults to an empty string.
0 Karma


We need that field. There are multiple reports/use cases.
I checked on our splunk 6.3.0 setup. We are not getting this message.
Can you please suggest the work around?

0 Karma


Not issue of 6.4.1 upgradation?

0 Karma
Get Updates on the Splunk Community!

.conf24 | Day 0

Hello Splunk Community! My name is Chris, and I'm based in Canberra, Australia's capital, and I travelled for ...

Enhance Security Visibility with Splunk Enterprise Security 7.1 through Threat ...

 (view in My Videos)Struggling with alert fatigue, lack of context, and prioritization around security ...

Troubleshooting the OpenTelemetry Collector

  In this tech talk, you’ll learn how to troubleshoot the OpenTelemetry collector - from checking the ...