Splunk® Universal Forwarder

Forwarder Manual

This documentation does not apply to the most recent version of Splunk® Universal Forwarder. For documentation on the most recent version, go to the latest release.

Known issues

This topic lists known issues that are specific to the universal forwarder. For information on fixed issues, see Fixed issues.

Universal forwarder issues

Date filed Issue number Description
2020-11-09 SPL-197140, SPL-234386 UF failed to start on Solaris 11.3 with error: "symbol in6addr_any: referenced symbol not found"

Workaround:
1. Do not upgrade past Splunk 8.0.5 on Solaris 11.3

OR 2. Upgrade to Solaris 11.4

2019-05-28 SPL-171178, SPL-167307, SPL-202078 Indexer Acknowledgement causes metric index events that do not have "_raw" fields to be duplicated

Workaround:
Indexer acknowledgement is a feature that helps prevent loss of data when forwarders send data to an indexer. Indexer acknowledgement is controlled by the Boolean useACK setting in inputs.conf and outputs.conf.

Indexer acknowledgement uses the _raw field to track completeness of delivery for each event. In some cases, when an event does not contain a valid _raw field, Splunk servers fail to determine whether the event is completely delivered and do not return acknowledgement for it, even when the event is processed successfully. As a result, the forwarder sends the same event again, leading to duplication of indexed data. This can affect metric indexes, where events with the JSON source type will not have _raw fields.

When this issue occurs, the workaround is to set useACK=false to disable indexer acknowledgement. You may want to set up multiple forwarding/HEC channels or ports with two useACK settings, to meet the needs of both kinds of source events: those that contain the _raw field and those that do not.

2018-04-10 SPL-153251 Universal Forwarder txz package cannot be installed on FreeBSD 11.1

Workaround:
1. Use pkg install instead of pkg add

OR 2. Install package by untarring tgz file to /opt/splunkforwarder

2017-03-20 SPL-139019 Possible compatibility issues between Python / SDK clients and new 6.6 and later default sslVersions, cipherSuites

Workaround:
Users can do either of the following:

1. Overwrite the new Splunk 6.6 server.conf [sslConfig] sslVersions, cipherSuites with your own settings that are compatible with your version of OpenSSL, e.g. the previous defaults from 6.5.x are compatible with OpenSSL 0.9.8 on Mac OSX:

[sslConfig]
sslVersions = *,-ssl2
sslVersionsForClient = *,-ssl2
cipherSuite = TLSv1+HIGH:TLSv1.2+HIGH:@STRENGTH

2. For some more up-to-date clients, it is possible to enforce TLS1.2 (e.g. --tlsv1.2 for curl) in order to connect successfully.

3. Upgrade OpenSSL on your platform and link it with your client (e.g. Python, curl, etc..). For example, OpenSSL 1.0.2 is currently available on Mac OSX via Homebrew (see https://brew.sh) and is compatible with the new Splunk 6.6 default sslVersions, cipherSuites.

2017-03-14 SPL-138731 New 6.6 and later default SHA256/2048-bit key certificates are not compatible with previous versions SHA1/1024-bit key certificates if cert verification is enabled

Workaround:
Users can do any of the following:

1. Disable certificate verification - the same root certificate is available with every Splunk download so enabling certificate verification while using the default certificates provides very little additional security.

2. Generate new SHA256/2048-bit key certificates using the new 6.6 root certificate and distribute to older versions of Splunk

3. Generate SHA1/1024-bit key certificates using the old root certificate to use with your new 6.6 instance. For convenience, the old root certificate is included in 6.6 in $SPLUNK_HOME/etc/auth/prev_release/

2015-06-10 SPL-103010 Indexing throughput on a forwarder with four pipelinesets drops 30% compared to a forwarder with two pipelinesets.
2015-04-14 SPL-99687, SPL-129637 Splunk universal forwarder is 7-10 days behind recent Windows Security and system log events.

Workaround:
To mitigate this, edit the following stanza in inputs.conf: [WinEventLog://Security] evt_resolve_ad_obj = 0.
2015-04-07 SPL-99316 Universal Forwarders stop sending data repeatedly throughout the day

Workaround:
In limits.conf, try changing file_tracking_db_threshold_mb in the [inputproc] stanza to a lower value.
2015-03-25 SPL-98594 Routing events to two different groups not working as expected.

Workaround:
1 On the original UF, instead of configuring 1 s2s and 1 syslog group, configure 2 s2s groups.

2 Setup a proxy UF which takes input from the original UF and send input out syslog server. This solution only requires config change and no patch release is required.

2014-08-05 SPL-88396 After configuring a client name for a deployment client, the name is not shown in the Forwarder Management UI

Workaround:
Create a server class, where you can see the client name, and use that group when you add data.
Last modified on 29 October, 2024
Troubleshoot the universal forwarder   Fixed issues

This documentation applies to the following versions of Splunk® Universal Forwarder: 8.2.10


Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters