[Dnsmasq-discuss] dnsmasq using 100% of cpu
Simon Kelley
simon at thekelleys.org.uk
Mon Mar 2 22:42:33 GMT 2020
On 02/03/2020 22:00, Geert Stappers wrote:
> On Mon, Feb 17, 2020 at 08:32:49PM +0000, Simon Kelley wrote:
>>
>>
>> On 17/02/2020 13:31, Donald Sharp wrote:
>>> Running:
>>>
>>> sharpd at eva:~/dnsmasq$ /sbin/dnsmasq --version
>>> Dnsmasq version 2.80 Copyright (c) 2000-2018 Simon Kelley
>>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>>> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
>>> ----
>>>
>>> When I install several hundred thousand routes into the kernel and
>>> remove them( or some variation thereof ), dnsmasq eventually ends up
>>> running 100% cpu:
>>>
>>> top - 18:45:18 up 1 day, 7:44, 1 user, load average: 2.70, 2.65, 2.34
>>> Tasks: 424 total, 3 running, 421 sleeping, 0 stopped, 0 zombie
>>> %Cpu(s): 12.1 us, 6.9 sy, 0.0 ni, 80.2 id, 0.0 wa, 0.0 hi, 0.7 si,
>>> 0.0 st
>>> MiB Mem : 32131.3 total, 19483.6 free, 6620.3 used, 6027.4 buff/cache
>>> MiB Swap: 32718.0 total, 31693.0 free, 1025.0 used. 24698.2 avail Mem
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
>>> COMMAND
>>> 293183 nobody 20 0 11040 2040 1688 R 99.7 0.0 148:48.40
>>> dnsmasq
>>>
>>> strace output:
>>>
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=POLLERR}])
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
> ...
>>> poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5,
>>> events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8,
>>> events=POLLIN}], 6, -1) = 1 ([{fd=4, revents=PO^Cstrace: Process 293183
>>> detached
>>>
>>> I can pretty much make this happen at will. What can I provide to help
>>> debug this?
>>
>> The first thing I'd like to know is what file descriptor 4 is, providing
>> us with the first (say) 500 or 1000 lines of strace output would help
>> with that.
>>
>>
>>>
>>> As a side note, I was not placing these routes into the default linux
>>> routing table. Does dnsmasq need to be paying attention to these routes?
>>>
>>
>>
>> To save typing I've just pasted a comment from the code which explains
>> why adding routes affects dnsmasq
>>
>> /* We arrange to receive netlink multicast messages whenever the
>> network route is added.
>> If this happens and we still have a DNS packet in the buffer,
>> we re-send it.
>> This helps on DoD links, where frequently the packet which
>> triggers dialling is
>> a DNS query, which then gets lost. By re-sending, we can avoid
>> the lookup
>> failing. */
>>
>>
>> I suspect that the solution to this is to restrict the above to the
>> "main" routing table.
>>
>
> Matching that with "[PATCH] Ignore routes in non-main tables"
> ( http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013824.html )
>
>
That's a good solution. Donald, if you could supply an answer to the
question about what fd 4 is, that would still be useful too.
Simon.
>
> Regards
> Geert Stappers
>
More information about the Dnsmasq-discuss
mailing list