SourceTypes being changed by GUI

[KeithH]

Hi All,

Help please.

Can I get people to agree with me that the following is a bug/design flaw - as my splunk case is getting no where.  

Please try this, it only takes a moment, promise...

1. In the splunk gui go to sourcetypes
2. Click New Source Type
3. give it a name - maybe test
4. Click advanced
5. Delete the  LINE_BREAKER setting
6. Add New Setting:   BREAK_ONLY_BEFORE and set value to AAAA
7. Check/Set SHOULD_LINEMERGE is true
8. Save
9. Run this search to confirm your settings look good:

| rest /servicesNS/-/-/configs/conf-props| where title = "test" | fields BREAK_ONLY_BEFORE LINE_BREAKER SHOULD_LINEMERGE eai:acl.removable eai:acl.sharing eai:appName title​

• In the search results confirm values have been saved as expected
• Re-edit the source type in the gui
• Click Advanced
• Notice that SHOULD_LINEMERGE has been changed to false and LINE_BREAKER has been returned and set to AAAA

So the GUI is changing settings when a user re-edits the sourcetype.  Perhaps the user just wanted to changed the sourcetype descriptions and they saved that would mean the sourectype no longer works.

I reckon this is a bug or design flaw but Splunk Support are trying to say it is expected behaviour.

Please feel free to agree with Splunk Support if you think I am missing something.

Thanks, Keith

[livehybrid]

Hi @KeithH 

So - I have tested as you suggested and found the same results as you. 

In terms of it beings a bug - I'm leaning towards agreeing with you on that front - its certainly unexpected user to the behaviour, however I'm wondering if its kind of intentional and possibly not actually affecting things under the hood. 

The props.conf on this are a little hazy if you ask me, but basically if you are using LINE_BREAKER then SHOULD_LINEMERGE should be set to False *and* you should include a regex with a capture group which is used to determine the end of the first event and start of the second.

It then says that when SHOULD_LINEMERGE is true, you should set one/many additional fields, one of which is BREAK_ONLY_BEFORE. 

Obviously in your example you have SHOULD_LINEMERGE=true and a BREAK_ONLY_BEFORE but it kind of looks like Splunk is converting this to a SHOULD_LINEMERGE=false with a LINE_BREAKER of the BREAK_ONLY_BEFORE. Since SHOULD_LINEMERGE=false at this point, the BREAK_ONLY_BEFORE is presumably ignored? 

At this point the LINE_BREAKER is "AAAA" as per your example, however it doesnt meet the spec documentation which states it should have a capture group in the Regex! So it feels like even if this is the case, it doesnt follow the docs and also seems like it makes some of these settings meaningless if you can just specify it in LINE_BREAKER afterall!? 

*Something* isnt right - Support might be claiming that it isnt a bug because it works as intended, but I think this means that the docs are incorrect? If nothing else, the values rendered in the WebUI shouldnt change from the contents in the actual conf files without user interaction? I think some sort of warning/explanation is needed if that is the case!

Anyway, lets see if others also have opinions on this and good luck with the bug/support case!

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[isoutamo]

I haven't tested it, but believe what you other have found.

But as currently Splunk has some GUI tools like IA (ingest action) etc. there is a small possibility that this is a planned way to work? As @livehybrid said there are best practices how those The 8 should be set based on those other values.

You probably will create a support case for this and then we will get official answer is this bug or planned feature?

[KeithH]

Thanks - will be interesting to see what others think.

[kiran_panchavat]

@KeithH 

[KeithH]

Thank Kiran - do you agree it should work this way?

[kiran_panchavat]

@KeithHYes, I agree. As @livehybrid  mentioned, a warning or some form of explanation would be appropriate in this situation.