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@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
> 


_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to