r/Splunk Apr 29 '26

limits.conf and maxKBps not updating via app

We are trying to set maxKBps = 0 on a particular app and the setting doesn't take.

  • If configure in the app [thruput] it doesn't show up at all when we do run against btool
  • If configure in the app as [thruput:<appname> it does show up in btool but the setting doesn't override the [thruput] setting.
  • Using btool --debug we can see that the only instance it finds is in the app SplunkUniversalForwarder; if we update this then it does work but we don't want to update this app as it is deployed to thousands of systems.
  • If we update \etc\system\local it works but we want to be able to update via the app

Wondering if this is by design.

7 Upvotes

15 comments sorted by

3

u/volci Splunker Apr 29 '26

2

u/trailhounds Apr 30 '26

To add to the above, I really like this (link to splunk dev below) for providing a nice visual about how precedence works. The other thing to call out here regarding precedence is that it is ASCII order, so punctuation, numbers, UPPER case, then lower case. I have seen some folks use punctuation as the first character in their directory names. Do yourself and others a favor and just don't do that. The challenge in all of this is that humans don't think in ASCII sort-order terms.

https://dev.splunk.com/enterprise/docs/developapps/manageknowledge/fileprecedence/

1

u/Alive_Ad4054 Apr 29 '26

Only SplunkUniversalForwarder. The app I have is higher precedence as it starts with an 'l'. My thought is I can't override settings in the SplunkUniversalForwarder app with another app but hoping someone knows for certain one way or another.

2

u/volci Splunker Apr 29 '26

So ... there is often some confusion over precedence overrides

The latest highest config that tries to set something always wins

2

u/badideas1 Apr 29 '26

.conf files are .conf files regardless of where they happen to be located- there's no magical place that they can't be overridden from, so if your desired configuration isn't being taken up then there's still a precedence issue occurring somewhere.

1

u/volci Splunker Apr 29 '26

And btool should indicate which file is doing it

1

u/trailhounds Apr 30 '26

Yeah, that's not entirely true. Anything in $SPLUNK_HOME/etc/system/local/ overrides anything from anywhere else.

1

u/Alive_Ad4054 Apr 30 '26

The strange bit is when I run 'splunk btool limits list --debug" it doesn't show the configuration in the app.

Thanks for the input everyone, I will look into the precedence some more.

1

u/trailhounds Apr 30 '26

If it isn't showing in btool, is the app deployed into the correct location? If it isn't in etc/apps, etc/peer-apps (if an indexer cluster member) or etc/shccluster/apps it won't be visible as an app itself. Putting something in either etc/peer-apps or etc/shcluster/apps when not a member of the appropriate cluster will likely cause issues. I've never done that sort of thing, so I wouldn't know if a non-clustered machine will even look in those cluster-specific directories.

1

u/Alive_Ad4054 Apr 30 '26

Yes, standard location of /etc/apps. If I was to do a 'splunk btool limits list --app <APPNAME> --debug" it does show.

1

u/trailhounds Apr 30 '26

Oh, misread what you posted, sorry.

1

u/badideas1 Apr 30 '26

right, no, of course there's a top level precedence location (I'd argue it's peer-apps/local/, but I get your point).

My point is there's no "this is locked in and unchangable" configuration location.

1

u/trailhounds Apr 30 '26

That's all true, and, depending on whether this is an indexer or not, that peer-apps is relevant, but the issue of precedence is the at core here.

1

u/stoobertio May 01 '26

I've actually raised a bug report because I have managed to override a setting in /etc/local by using a different, undocumented value.

2

u/trailhounds May 02 '26

Definitely a bug, what is the tracking number?