I noticed that some roles had the "scheduled_rtsearch" capability, and I removed them from both of my search heads, via Splunk Web. I then noticed on some indexers, some processes running with "rt_scheduler" listed, which, I believe, indicates a scheduled real-time search.
I then went back into the role, and the "scheduled_rtsearch" capability was back. I'm quite certain that I had removed it.
We are running 6.4.1, using Search Head Pooling (SHP).
Having similar issues with 6.5.1. Changed the ../etc/system/local/authorize.conf to start with
And that solved the re-appearing capability in my power role. BUT. Since a few months (upgrade related?) power got its rtsearch capability back. Eventhough configured:
rtsearch = disabled
and changed on advice of our local splunk rep the default part from above to
After restarting splunk power gets its rtsearch back. Not always it seems, weird enough. Wondering how to finally enforce the disabling of rtsearch; don't like to keep reminding to remove it after a restart.
Sounds like a case for detective
[btool] with the
--debug flag (https://docs.splunk.com/Documentation/Splunk/6.5.0/Troubleshooting/Usebtooltotroubleshootconfigurati...)
Something like this should show which file it's coming from, which should then allow you to work backwards to identify where this is being deployed from:
./splunk btool authorize list --debug | grep scheduled_rtsearch - this will bring back results for all roles so make sure you're looking at the one you want it removed from.
Also, some capabilities are inherited from any role inheritance. It should show up in a separate menu item in the GUI and only in the inherited role's capabilities on the config (and btool). Therefore, I assume that is not at play here.
I experienced exactly the same thing when I was configuring capabilities.
I then eventually configured the capabilities for the different roles via authorize.conf.
Since then no capability ever had the courage to just walk past me anymore.