Make dnstap work reliably with netmgr
The introduction of netmgr doubled the number of threads from which dnstap data may be logged: previously, it could only happen from within taskmgr worker threads; with netmgr, it can happen both from taskmgr worker threads and from network threads. Since the argument passed to fstrm_iothr_options_set_num_input_queues() was not updated to reflect this change, some calls to fstrm_iothr_get_input_queue() can now return NULL, effectively preventing some dnstap data from being logged. Whether this bug is triggered or not depends on thread scheduling order and packet distribution between network threads, but will almost certainly be triggered on any recursive resolver sooner or later. Fix by requesting the correct number of dnstap input queues to be allocated.
This commit is contained in:
committed by
Ondřej Surý
parent
96959447c3
commit
77dc091855
2
bin/tests/system/dnstap/ns3/named.args
Normal file
2
bin/tests/system/dnstap/ns3/named.args
Normal file
@@ -0,0 +1,2 @@
|
||||
# Using "-n 1" allows GL #1795 to be reliably reproduced
|
||||
-D dnstap-ns3 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 -n 1
|
||||
Reference in New Issue
Block a user