Bug #1524
closedPotential Thread Name issues due to RHEL7 Interface Naming Contentions
Description
I have begun testing Suricata on RHEL7, on an interface named "enp132s0." The length of this interface name resulted in the following thread names for my 16 threads:
RxPcapenp132s01
RxPcapenp132s02
RxPcapenp132s03
RxPcapenp132s04
RxPcapenp132s05
RxPcapenp132s06
RxPcapenp132s07
RxPcapenp132s08
RxPcapenp132s09
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
RxPcapenp132s01 <--
Furthermore, the stats log only displayed threads 1-9.
$ grep flow /var/log/suricata/stats.log | tail -20
flow.emerg_mode_entered | FlowManagerThread | 0
flow.emerg_mode_over | FlowManagerThread | 0
flow.tcp_reuse | FlowManagerThread | 0
tcp.no_flow | RxPcapenp132s01 | 0
tcp.no_flow | RxPcapenp132s02 | 0
tcp.no_flow | RxPcapenp132s03 | 0
tcp.no_flow | RxPcapenp132s04 | 0
tcp.no_flow | RxPcapenp132s05 | 0
tcp.no_flow | RxPcapenp132s06 | 0
tcp.no_flow | RxPcapenp132s07 | 0
tcp.no_flow | RxPcapenp132s08 | 0
tcp.no_flow | RxPcapenp132s09 | 0
flow_mgr.closed_pruned | FlowManagerThread | 0
flow_mgr.new_pruned | FlowManagerThread | 31431
flow_mgr.est_pruned | FlowManagerThread | 0
flow.memuse | FlowManagerThread | 464960416
flow.spare | FlowManagerThread | 1050507
flow.emerg_mode_entered | FlowManagerThread | 0
flow.emerg_mode_over | FlowManagerThread | 0
flow.tcp_reuse | FlowManagerThread | 6
This truncation in the thread names can be traced back to the following:
From tm-threads.h:
#define TM_QUEUE_NAME_MAX 16
#define TM_THREAD_NAME_MAX 16
And from util-runmodes.c, RunModeSetLiveCaptureWorkersForDevice:
for (thread = 0; thread < threads_count; thread++) {
char tname[TM_THREAD_NAME_MAX];
...
snprintf(tname, sizeof(tname), "%s%s%"PRIu16, thread_name, live_dev, thread+1);
I can certainly look into changing the name of my interface to something shorter, but I figured this was worth mentioning since RHEL7 has adopted a new interface naming convention, and this seems to cause issues with stats reporting.
Perhaps the fix is as simple as raising the #define MAX's to 32, but I wasn't sure if that would have unwanted consequences.