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

[jishelar]

Hi,

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
Done

// Content of my transforms.conf file

[header_nullq]
DEST_KEY = queue
REGEX = ^TimeStamp
FORMAT = nullqueue

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

Thanks,
Jitendra

[sylim_splunk]

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.

[ddrillic]

You probably should run splunk btool check --debug.

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

[jishelar]

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
[eventtype=header_nullq]
DEST_KEY = queue
REGEX = ^TimeStamp
FORMAT = nullqueue

[jkat54]

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:

[header_nullq]
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
    match.
  * 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
    follows:
    * FORMAT = <field-name>::<field-value>( <field-name>::<field-value>)*
      where:
      * 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.

[jishelar]

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?

[jishelar]

Not issue of 6.4.1 upgradation?