Getting Data In

Windows Universal Forwarder default scripted inputs do not respect "disabled=" parameter.

jimodonald
Contributor

I have been trying to disable the disable the default scripted inputs from a Windows Universal Forward (version 6.2.1 and version 6.1.3) running on a Windows 2008 R2 server but the scripts do not appear to respect the "disabled=" parameter in inputs.conf. The reason for trying to disable the scripted inputs is twofold: first, we are not collecting the data; and second, when they execute they consume 100% CPU, albeit very briefly, but there have been concerns from the server owners about the impact of the Splunk Universal Forwarder running on the server as they see the higher CPU usage attributed to the UF.

Specifically, I've taken the stanzas from $SPLUNK_HOME/etc/system/default/inputs.conf (see below) and copied them into $SPLUNK_HOME/etc/system/local/inputs.conf with the scripted inputs (admin, MonitorNoHandle, WinNetMon, WinPrintMon, WinRegMon, and perfmon) all getting "disabled=1" added to their stanzas. However, the scripts still execute every 60 seconds and can be seen in Task Manager. Is this behavior by design or a bug?

I have found a workaround by changing the "interval=xx" parameter to just "interval=". With that parameter set to blank the scripts execute one time when Splunk UF starts/restarts but not again after the first time.

Is there a better way to disabled these scripted inputs?


$SPLUNK_HOME/etc/system/default/inputs.conf

[script://$SPLUNK_HOME\bin\scripts\splunk-wmi.path]
disabled = 0
interval = 10000000
source = wmi
sourcetype = wmi
queue = winparsing
persistentQueueSize=200MB

# default single instance modular input restarts

[admon]
interval=60
baseline=0

[MonitorNoHandle]
interval=60

[WinEventLog]
interval=60
evt_resolve_ad_obj = 0
evt_dc_name=
evt_dns_name=

[WinNetMon]
interval=60

[WinPrintMon]
interval=60

[WinRegMon]
interval=60
baseline=0

[perfmon]
interval=300

$SPLUNK_HOME/etc/system/local/inputs.conf

[default]
host = WINDOWS_HOST

[WinEventLog://Application]
checkpointInterval = 5
current_only = 0
disabled = 0
evt_resolve_ad_obj = 1
start_from = oldest

[WinEventLog://Security]
checkpointInterval = 5
current_only = 0
disabled = 0
evt_resolve_ad_obj = 1
start_from = oldest

[WinEventLog://System]
checkpointInterval = 5
current_only = 0
disabled = 0
evt_resolve_ad_obj = 1
start_from = oldest


# default single instance modular input restarts

[admon]
interval=60
baseline=0
disabled=1

[MonitorNoHandle]
interval=60
disabled=1

[WinEventLog]
interval=60
evt_resolve_ad_obj = 0
evt_dc_name=
evt_dns_name=

[WinNetMon]
interval=60
disabled=1

[WinPrintMon]
interval=60
disabled=1

[WinRegMon]
interval=60
baseline=0
disabled=1

[perfmon]
interval=300
disabled=1
1 Solution

jimodonald
Contributor

It's a bug. I submitted a ticket to Splunk support and they responded with:

its a known bug SPL-92479, where the scripted input created via REST on universal forwarder does not honor disabled=true setting.
For the UF currently running on 6.1.3, the issue has been address in release 6.1.5. [A fix is pending] for 6.2.1.

So there you go. It is not the expected behavior, it's a bug.

View solution in original post

0 Karma

dshakespeare_sp
Splunk Employee
Splunk Employee

It appears this behavior is by design and is not really a bug.

All "disabled = 1" means is the inheriting input stanzas should be disabled, not that the modular input is disabled.
A notion of disabled modular inputs does not exist in Splunk. Though, a modular input can be part of a disabled app, in which case the modular input will not be initialized (behaves as if it didn't exist).

So this is by design to allow maximum flexibility. Even if all input stanzas are disabled, it may be appropriate for a process to start and "do something".

The only way to get around this design annoyance is to also add "interval=-1" to the disabled stanza. This means the processes will run ONCE only at startup

niemesrw
Path Finder

Was this ever fixed? I'm seeing the same behavior in UF 6.3.3

jimodonald
Contributor

It's a bug. I submitted a ticket to Splunk support and they responded with:

its a known bug SPL-92479, where the scripted input created via REST on universal forwarder does not honor disabled=true setting.
For the UF currently running on 6.1.3, the issue has been address in release 6.1.5. [A fix is pending] for 6.2.1.

So there you go. It is not the expected behavior, it's a bug.

View solution in original post

0 Karma

jimodonald
Contributor

I have not installed the Windows add-on, as we are not interested in that data currently. Right now we just want the event logs.

I do not remember seeing the option to disable any of the default inputs during the installation of the UF. I'll have to go back and see if they are there.

Sure it's redundant to have the default parameters specified in $SPLUNK_HOME/etc/system/local but by having them present should not have any impact on the effects of the disabled parameter, IMHO. If their existence alongside the disabled parameter impacts the functionality of "disabled=", I would consider that a bug -- it is not the documented or desired behavior. What happens when I need to temporarily disable an input? I add "disabled=1" to the stanza and restart the UF.

As it stands now, I'm going to open a ticket with Splunk and file it as a bug.

0 Karma

lguinn2
Legend

A support ticket is a good idea, as support can go through the forwarder logs, etc for you.

The redundant parameters are not simply redundant - the local system directory has a very high precedence in configuration conflict resolution, while the default directory has a low precedence. So you have changed the precedence for all the attributes that you copied. This will probably not make any difference in your environment, but it could. So only specifying the necessary attributes (disabled=1) in $SPLUNK_HOME/etc/system/local/inputs.conf is the best practice.

Configuration File Precedence

0 Karma

lguinn2
Legend

Your $SPLUNK_HOME/etc/system/local/inputs.conf should really look like this:

[WinRegMon]
 disabled=1

 [perfmon]
 disabled=1

In other words, you only need to specify disabled=1 for each stanza. My guess is that these settings happened when the UF was installed - Application, System, and Security Windows Event Log inputs are enabled by default in 6.2. You should explicitly disable these during installation.

You might also want to check whether these inputs are defined anywhere else in your environment. Did you install the Windows add-on?

0 Karma
Register for .conf21 Now! Go Vegas or Go Virtual!

How will you .conf21? You decide! Go in-person in Las Vegas, 10/18-10/21, or go online with .conf21 Virtual, 10/19-10/20.