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@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
