{sigh}
So of course, today (2019-02-10) I can't reproduce the error.  I even went
up to the Extreme (762213 entries) pak, and increased the DNS cache to
10000, and it's humming along perfectly.

It is increasing the first lookup speed from ~50-70ms to ~400-500ms, but I
would consider that reasonable for a local lookup against 762213 entries!

If you would, keep the case open another day, and I'll leave it running.
Tomorrow it will be under greater load.

Thanks!!!

P.S. One question: When added via:
conf-file=/etc/dnsmasq.d/hosts/hosts.block.dnsmasq.conf are those entries
added to an in memory cache (separate from the lookup-cache I'm assuming?),
or at first-lookup does the application read the file (or a hashed temp
file it creates?) if the entry isn't already cached?

The Extreme file is 29MB, yet my current memory usage is:
              total        used        free      shared  buff/cache
 available
Mem:       16361824      401040    14150104        2052     1810680
15776944

Here's a dig lookup example:
dig library.usc.edu @192.168.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> library.usc.edu @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14105
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;library.usc.edu.               IN      A

;; ANSWER SECTION:
library.usc.edu.        3600    IN      CNAME   usclibraries.usc.edu.
usclibraries.usc.edu.   3600    IN      A       128.125.183.98

;; Query time: 559 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Feb 10 12:42:49 EST 2019
;; MSG SIZE  rcvd: 87





On Sun, Feb 10, 2019 at 8:17 AM Bernhard Übelacker <bernha...@mailbox.org>
wrote:

> Hello Zac Morris,
>
> >> Yeah, I didn't know how to update the case. Is there a web front-end for
> >> updating/tracking the cases? I couldn't figure out how to do it via
> email.
>
> You just need to send the answers also to 921...@bugs.debian.org
> as receiver or CC. Then all the information is collected in this page:
>
>     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921310
>
> >> The dmesg output was: segfault error 4 (memory?)
>
> Is this the complete line in dmesg output?
>
>
> Forwarding the information to the bug.
>
> Kind regards,
> Bernhard
>
>
> -------- Weitergeleitete Nachricht --------
> Betreff:        Re: Bug#921310: dnsmasq "segment fault" bug when total conf
> files size is too large
> Datum:  Sat, 9 Feb 2019 15:31:52 -0500
> Von:    Zac Morris <z...@zacwolf.com>
> An:     Bernhard Übelacker <bernha...@mailbox.org>
>
>
>
> Yeah, I didn't know how to update the case. Is there a web front-end for
> updating/tracking the cases? I couldn't figure out how to do it via email.
>
> The dmesg output was: segfault error 4 (memory?)
>
> So hopefully walking you through it might help?
>
> When I use the conf-file=parm in my config file to point to any of the
> dnsmasq formatted block lists provided by https://energized.pro/#packs,
> using anything larger than Basic (which contains about 466000 entries)
> causes the segfault error 4 after just a few DNS queries.
>
> Using Basic doesn't cause the segfault, but from the machine running
> dnsmasq, when I use a dig (using the Basic dnsmasq format file added via
> conf-file= ) it adds over 500ms to the lookup. (I got 4 seconds once,
> but haven't been able to replicate that again).  I didn't use this setup
> very long so it may have caused the segfault as well after some time.
>
> What I ended up doing is using the /etc/hosts version of the energized
> files.
> #my local static network devices
> addn-hosts=/etc/dnsmasq.d/hosts/hosts.local
> #Basic etc/hosts formated file provided by Energized.pro
> addn-hosts=/etc/dnsmasq.d/hosts/hosts.block
>
> When I do that I'm getting an average new domain lookup of 23ms
> non-dnssec, 65ms with dnssec), with 0ms on subsequent (cached, as
> expected) lookups either way.
>
> I understand that dnsmasq is geared more towards small memory devices,
> so this may not be a priority.
>
> It would seem that loading large address=based conf files causes a
> segfault error 4 if it's too larger, but if it's large (but not too
> larger) it adds substantial time to a lookup, but why would
> using addn-hosts= with the the same huge ~466000 entries add no time to
> the lookup nor cause an error 4?
>
>
> I'm attaching my current lan.conf which is loaded from the default
> /etc/dnsmasq.conf
>
> THANKS!!!
>
>

Reply via email to