Dnsmasq stops occasionaly

[ligand]

Hi Franco,
No change in behavior with the older version...

root@OPNsense:~ # cat dns_mem_usage.out
Fri Jan 30 06:40:33 EST 2026
  PID %CPU  RSS   VSZ COMMAND
80630  0.0 6176 17772 dnsmasq
Fri Jan 30 07:40:33 EST 2026
  PID %CPU   RSS   VSZ COMMAND
80630  0.0 19236 33644 dnsmasq
Fri Jan 30 08:40:33 EST 2026
  PID %CPU   RSS   VSZ COMMAND
80630  0.0 31632 46956 dnsmasq
Fri Jan 30 09:40:33 EST 2026
  PID %CPU   RSS   VSZ COMMAND
80630  0.0 47600 65388 dnsmasq
Fri Jan 30 10:40:33 EST 2026
  PID %CPU   RSS   VSZ COMMAND
80630  0.0 64412 92012 dnsmasq
Fri Jan 30 11:40:34 EST 2026
  PID %CPU   RSS    VSZ COMMAND
80630  0.0 79216 108396 dnsmasq
Fri Jan 30 12:40:34 EST 2026
  PID %CPU   RSS    VSZ COMMAND
80630  0.0 91224 128876 dnsmasq
Fri Jan 30 13:40:34 EST 2026
  PID %CPU    RSS    VSZ COMMAND
80630  0.0 107776 128876 dnsmasq
Fri Jan 30 14:40:34 EST 2026
  PID %CPU    RSS    VSZ COMMAND
80630  0.0 124400 153452 dnsmasq

[ligand]

Hi Cedrik,
Can you answer Simon's questions?

I just sent SIGHUP twice in succession to the dnsmasq process in my
OpenWRT router, with the new malloc-logging feature enabled.

HUP frees a load of configuration and the re-reads it and I correlated
all the memory freed by the second HUP with what was allocated in the
first HUP.

It's perfect. Every block is freed.


This is a fairly old installation, so old libraries, etc, but the very
latest dnsmasq code.

The configuration it's re-reading is pretty small.

I then tried your technique of hitting dnsmasq hard with many HUPs.

I had to go up to half a million to see much effect, but I guess most of
those were dropped since they will have arrived before the previous one
was cleared.

In any case I could see a reproducible rise of a few percent in the VSZ
of the process each time.

What's clear is that the configuration is stored in a _lot_ of small
allocations, so re-reading a substantial configuration  will free a lot
of small blocks and then malloc a lot of small blocks.

A quick Google produces some complaints about the fragmentation
performance of musl, which may be significant.

Is your installation using musl as the C library, and is it possible to
build dnsmasq against, say glibc to test?

Nearly all of the memory management on dnsmasq that gets hit by
answering DNS or DHCP requests avoid hammering the malloc system by
building pools of free data structures that get re-cycled as needed.
Once the pools have grown to equilibrium size, even a very busy server
hardly uses the heap. I guess the configuration code to use the same
policy, but it's a big re-write, and re-reading configuration on a
sub-second timescale is an unlikely use-case.




Cheers,

Simon.

[Monviech (Cedrik)]

Im not sure what to answer there, since it relates to another email in the same mailing list thread. And its about OpenWRT which is linux based. We don't even know if the issue reported there, and the issue you have are the same.

Yours is more clearly scoped around DHCPv6 and/or RA as it seems, and less likely  around configuration reloads (just going from heuristics, I don't know for sure).

Als you didnt test with an older version, you tested with 2.91 and 2.92 now.

If you must use a devel built with the --log-malloc option we can probably try to help offering something, but could you send your other logs yet that were requested earlier in the mailing list?

For reference Im following it here:
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/

[franco]

> No change in behavior with the older version...

Well, it's a newer version.  Did you restart Dnsmasq to be sure?

We can always try the latest development version, but it looks a bit like chasing ghosts at the moment.


Cheers,
Franco

[ligand]

Yup.  I restarted dnsmasq after the update. 

[ligand]

Here are the log files I sent Simon

https://drive.google.com/file/d/1N16fclaKNR6PaC3_f82hPn-mGaoRsuzI/view?usp=sharing

I couldn't post them directly here.