Heavy forwarder has many "TcpInputProc - Input queue has pds" lines in splunkd.log

[minhvt]

After upgrade from 9.1.0 to 9.2.1, my heavy forwarder has many following lines in log:

04-01-2024 08:56:16.812 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:16.887 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:16.951 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:16.982 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.008 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.013 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.024 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.041 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.079 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.097 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.146 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.170 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.190 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.257 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.292 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.327 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.425 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.522 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.528 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.549 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.
04-01-2024 08:56:17.551 +0700 INFO  TcpInputProc [103611 FwdDataReceiverThread] - Input queue has pds 0 after reader thread stopped.

How to disable this log? Does any error related this INFO log?

[wwangsa_splunk]

Hello Champs,

This message is info only and can be safely ignored. Alternatively, you can turn it off by setting the TcpInputProc log level to WARN.

If you can't restart splunkd yet, simply run:
$SPLUNK_HOME/bin/splunk set log-level TcpInputProc -level WARN

To make the change persistent:
* Create or edit $SPLUNK_HOME/etc/log-local.cfg

* Add:
category.TcpInputProc=WARN

* Followed by splunkd restart.

[Akeydel]

Running version 9.3, the log-local.cfg doesn't seem to be applied.
Even after a restart, Splunk is throwing >10 of these INFO lines per second.

This message should probably be moved to the DEBUG category... 

Spoiler

It is possible there's another issue with my instances, but this mess of logs is making it very hard to troubleshoot.
`splunk set log-level TcpInputProc -level WARN`  does work
Modifying log.cfg also works

[nkoppert_s]

Following this thread as well, as I have observed the same issue following an upgrade from 9.1.2 to 9.2.1

[Mitch_TA_Debug]

Still an issue in 9.3.2

The concept of "ignore all INFO level" messages doesn't sit with me well as a solution, there are useful messages at that level.

[jonrsplunk]

Same with 9.1.4.