Luci floods dnsmasq log with PTR queries

I'm using OpenWrt SNAPSHOT r14740-0b31713c85 on a FriendlyARM NanoPi R1.

For dnsmasq (version 2.82-6) I've enabled logging with the option to log queries (log-facility=/var/log/dnsmasq.log).

Just by accident I discovered, that luci is flooding about every 5 seconds dnsmasq with PTR queries, when I select the status overview. The flooding continues until I choose another menu.

Here's an excerpt from the dnsmasq log:

Feb 19 12:24:02 dnsmasq[8644]: 216639 127.0.0.1/39204 query[PTR] 73.40.89.10.in-addr.arpa from 127.0.0.1
Feb 19 12:24:02 dnsmasq[8644]: 216639 127.0.0.1/39204 DHCP 10.89.40.73 is TABLET-SMART
Feb 19 12:24:02 dnsmasq[8644]: 216640 127.0.0.1/39204 query[PTR] 21.25.91.10.in-addr.arpa from 127.0.0.1
Feb 19 12:24:02 dnsmasq[8644]: 216640 127.0.0.1/39204 /tmp/hosts/dhcp.cfg01411c 10.91.25.21 is LTC-PC
Feb 19 12:24:07 dnsmasq[8644]: 216641 127.0.0.1/40081 query[PTR] 50.25.91.10.in-addr.arpa from 127.0.0.1
Feb 19 12:24:07 dnsmasq[8644]: 216641 127.0.0.1/40081 /tmp/hosts/dhcp.cfg01411c 10.91.25.50 is DSA-NAS
Feb 19 12:24:07 dnsmasq[8644]: 216642 127.0.0.1/40081 query[PTR] 90.25.91.10.in-addr.arpa from 127.0.0.1

Luci asks for the PTR infos for every device, which has connected to the router since the last boot. That means: there are a lot of devices, which are currently not connected to the router.

The frequence and the amount of queries result in a rapidly growing dnsmasq log file. Because it resides in a tmpfs, this behaviour can make the router inoperable (out of ram memory).

Is there any chance to change this behaviour of luci?

It should be fine, since OpenWrt log uses ring buffer and its size is fixed:
https://openwrt.org/docs/guide-user/base-system/log.essentials

1 Like

Tried disabling the upper right corner auto update ?

2 Likes

It is not fine, because I've defined a logfile for dnsmasq (see my OP), and this logfile isn't a ring buffer, so it grows and grows ....

What's what logrotate's for.

Just tried it and the flooding stopped.

The default is REFRESHING, to avoid the flooding it should be PAUSED.

If I want an update of the page, I can press the reload button of my browser. I think, that's better than the flooding as a result of luci's refreshing.

I know logrotate and use it since several decades. But I prefer to get rid of the cause, and not mitigate the symptoms.

System log should rotate as specified in the settings:

uci show system; logread | wc

Dnsmasq query logging is disabled by default.
So, your problem is the result of your own customization.

If you believe this is a common issue, file a ticket here:
https://github.com/openwrt/luci/issues

I think, you are mixing up cause and result. Cause is luci's query flooding, the result is the growing dnsmasq logfile. My definition of a logfile for dnsmasq unveils luci's misbehaviour.

This behavior is likely intentional and not a problem for most users.
You can report it to the LuCI bug tracker as mentioned above.

I don't concur with you.

I can't see any useful need to query PTR infos for devices, which are neither connected nor have a valid lease record.

To be a problem for users they must be aware of the flooding. I'm using openwrt since 2017 and noticed this behaviour just a few weeks ago.

I'll give you some numbers to better describe this behaviour. The numbers are based on my network environment (about 10-15 connected devices).

The flooding adds about 5 MiB/hour to the log, normal is about 30 KiB. During 1 hour the log records 23878 queries, 23760 are PTR queries and 4355 of those relate to devices not connected resp. having no lease record.

As far as I remember on a fresh openwrt install the log buffer is set to 64 KiB. This 64 KiB ring buffer will be cluttered within 46 secs. Even if you adjust it to 1MiB, it will last only 12 minutes to wipe out all usefull information.

In my case I had defined a logfile solely for dnsmasq. This logfile grows by 5 MiB every hour. Depending on the RAM of your device it's just a matter of time, when you run out of memory. Your router reboots and (because all log info resides in volatile memory) you have no clue, why all this happened.

And you really think, that's not a problem?

I've been working for more than 4 decades as a system engineer and reviewed thousands, perhaps even millions lines of codes. The coding, which is responsible for the flooding, has been done by a person, who never really reflected the outcome of his/her coding.

If the developers of openwrt are interested in reliability and stability, they should improve this part of coding, because it eliminates a reason for a mysterious crash/reboot.

Not a problem until you properly report it to the bug tracker.
To be clear, this forum is not a bug tracker.

1 Like