[Dnsmasq-discuss] Memory usage growing over time — possibly due to logging or caching (v2.90 / OpenEmbedded kirkstone)

[Simon Kelley]

On 4/13/25 13:45, Nitesh Divecha via Dnsmasq-discuss wrote:
> Hi all,
> 
> I'm using dnsmasq version 2.90 in an embedded Linux project based on the Yocto Project (kirkstone branch). The recipe in use is from the OpenEmbedded meta-networking layer: https://layers.openembedded.org/layerindex/recipe/304520/
> 
> I've observed that dnsmasq memory usage steadily increases over time, even under light DNS query loads. For example:
> 
> - On boot: ~1.1 MB
> - After 1 hour: ~3.3 MB
> - After ~14 hours: ~15.3 MB
> 
> Relevant configuration (via NetworkManager):
> # cat /etc/NetworkManager/dnsmasq.d/dnsmasq-dns.conf
> no-negcache
> stop-dns-rebind
> 
> server=8.8.8.8
> server=1.1.1.1
> 
> all-servers
> 
> log-queries
> log-facility=/var/log/dnsmasq.log
> 
> 
> I noticed that the `/var/log/dnsmasq.log` file grows continuously (currently ~15M), and suspect that this may be contributing to memory growth — either due to internal buffering or cumulative logging state.
> 
> My questions:
> 1. Is this memory growth expected when `log-queries` is enabled with `log-facility`?
> 2. Does `dnsmasq` buffer log output internally, or are there known issues with memory not being reclaimed after prolonged logging?
> 3. Are there recommended best practices for logging in long-running embedded environments to avoid this kind of memory usage?
> 
> Any suggestions or insights would be greatly appreciated.
> 
> Thanks in advance,
> 
> Cheers,
> Nitesh
> 
> 

Do you only see this memory-size growth when logging to a file? It's 
possible that there's a memory leak elsewhere, but unlikely that one 
that big could have been undetected until now.

It's possible that the libc in use is memory-mapping the log file. 
Dnsmasq uses very standard open() and write() calls, but it's up to the 
libc how it implements that. Memory-mapping the file and converting 
write() calls to memory writes would be a legitimate thing to do. In 
this case some measures of the process's memory usage would increase, 
but the actual physical RAM usage would not - long untouched pages will 
be written out to the filesystem and the RAM freed for reuse, just like 
swapping.

Dnsmasq allows log-file rotation in the conventional way. The simplest 
thing to do is to delete the log file and then send the dnsmasq process 
SIGUSR2. That makes dnsmasq close and reopen the file. The close removes 
the last reference to the deleted file and its disk storage is freed-up. 
The re-open creates a new log file which begins empty. Real logfile 
rotation renames the live file instead of deleting it, and only deletes 
old logfiles after a few days: see man logrotate for details on that.


Cheers,

Simon.





> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss