Dnsmasq repeatedly crashes on OpenWrt — need help identifying root cause

Installing and Using OpenWrt
21

procd‑managed services indeed don’t disappear silently — that’s exactly why I’m running dnsmasq outside of procd to capture a core dump. Here is the minimal PID‑based monitoring script I use. It doesn’t rely on AI, procd, or any heuristics — it simply checks whether the process is still alive:

#!/bin/sh
TARGET="dnsmasq"
PIDFILE="/var/run/dnsmasq_manual.pid"
LOG="/loghub/dnsmasq_manual/monitor.log"

mkdir -p "$(dirname "$LOG")"

while true; do
    if [ -f "$PIDFILE" ]; then
        PID=$(cat "$PIDFILE")
        if ! kill -0 "$PID" 2>/dev/null; then
            echo "$(date '+%Y-%m-%dT%H:%M:%S%z') [CRASH] dnsmasq disappeared (PID=$PID)" >> "$LOG"
        fi
    else
        echo "$(date '+%Y-%m-%dT%H:%M:%S%z') [WARN] PID file missing" >> "$LOG"
    fi
    sleep 1
done

And here is what the watcher logs when dnsmasq crashes:

[2026-02-04T10:09:18+0300] [INFO] dnsmasq PID:3875 uptime: 01:38:40
[2026-02-04T10:11:49+0300] [WARN] port 53 is no longer listening
[2026-02-04T10:11:49+0300] [CRASH] dnsmasq disappeared (PID=3875)
[2026-02-04T10:12:38+0300] [CRASH] dnsmasq disappeared (PID=24964)

There is:

  • no SIGTERM
  • no SIGKILL
  • no OOM
  • no kernel messages
  • no syslog entries
  • no exit code

The process simply vanishes, which is why I’m enabling core dumps to capture the actual crash reason.

Once I get the core, I’ll analyze it with gdb and share the backtrace.

1 Like
22

I don't know if this info helps, but from what I learned with self compiled images, I guess it is self compiled? If the buildtools have overwritten file permissions and maybe even chowns, I had everything set on 755.

The wrong permissions can result in your firmware build, I have had this for some time and I had really strange dnsmasq symptoms, like no routing passthrough on firstboot, had to reboot a second time for function, after upgrading, but also pbr not wanting to launch also only on the second boot, the weird thing is the routes in ip r where perfectly present, but yet it was a full lockup, also zero error whatsoever.

Wan didn't want to get dhcp however.

I did a clean checkout of OpenWrt main and basicly manually checked out my own scripts from origin and force pushed everything with the correct permissions,no issue since then, likely it even fixes more problems which I had.

23

Nothing wrong, you might log netstat -lnpu | grep :53

Run

gdb dnsmasq
# gdb> 
run param param param

when it dies return to session and look at what happened...

24

The issue is not related to file permissions, buildroot artifacts, or configuration migration. The firmware was self‑built, but no system‑level permissions or init scripts were modified. The same crash behavior occurred earlier on FriendlyWRT and now on stock OpenWrt with clean, default configurations. Nothing significant in the system was changed.

dnsmasq does not fail at boot; it runs normally for hours or even days and then terminates unexpectedly. Crashes are irregular: it may run for long periods without issues, then crash multiple times in a row, and then remain stable again. When it happens, the process disappears instantly, port 53 stops listening, and there are no syslog entries, no dmesg output, no kernel messages, and no exit code. The system provides no diagnostic traces.

Given that the behavior is identical across different firmware bases, toolchains, and configurations, and that the crashes occur only at runtime and leave no logs, the most plausible cause is an internal dnsmasq runtime fault (e.g., race condition, memory corruption, or similar). I’m running dnsmasq outside of procd specifically to capture a core dump; once obtained, I’ll analyze the backtrace.

25

The issue isn’t that I’m missing logs or not checking port 53 — my watcher already records the exact moment when dnsmasq stops listening and when the PID disappears. The problem is that dnsmasq doesn’t exit through a normal code path. It terminates instantly with no syslog, no dmesg, no kernel message, and no exit code. The process simply vanishes.

Running dnsmasq under gdb is not feasible here because the crash happens after many hours or even days of normal operation, and sometimes not at all. It’s not a reproducible crash-on-start; it’s a long‑uptime runtime fault. That’s why I’m running dnsmasq outside of procd with core dumps enabled — so the next unexpected termination will produce a core file that can be analyzed with gdb afterwards.

Once I get the core dump, I’ll load it into gdb and inspect the backtrace.

26

Just run gdb in screen or something.
Do USR1 stat every 5 mins or so - if some number grows, or just runs away suddenly.
Probably worth teanferring your configs to srandard bulld so that we can expand on library offsets.

27

Running dnsmasq under gdb isn’t practical in this case — the crash happens after many hours or even days of normal operation, and sometimes not at all. It’s not a reproducible crash-on-start, so keeping gdb attached in a screen session doesn’t help.

USR1 stats also won’t detect this issue: dnsmasq doesn’t show any abnormal growth or runaway counters before the crash. The process simply disappears instantly with no logs, no signals, and no exit code.

The same behavior occurs on FriendlyWRT and on stock OpenWrt with clean default configs, so it’s not related to my build or configuration. I’m running dnsmasq outside of procd with core dumps enabled; once it terminates unexpectedly, I’ll analyze the core with gdb to get the actual backtrace.

28

Well, then do nothing?

3 Likes
29

The issue isn’t about “doing nothing.” The problem is that dnsmasq doesn’t produce any logs, warnings, or exit codes before it disappears, and the crash is not reproducible on demand. That’s why the only meaningful action is to run it outside of procd with core dumps enabled and wait for the next unexpected termination. Once a core file appears, I can analyze the backtrace and identify the actual cause. Until dnsmasq produces a core, there’s nothing further to diagnose.

30

There were some problems reported which were fixed in DNSMasq 2.92

31

Humans — don’t use emdashes, but the community doesn’t like that Lantis can smell LLMs from a mile away so the post is edited. :person_shrugging:

The only valid debugging next steps are to strip this back to a default dnsmasq config and reapply changes one at a time until the bug resurfaces.

7 Likes
32

option max_file_limit '2048'
option bind_dynamic '1'

Neither of these are valid or parsed by the default init script.

list confdir

Is invalid and should be an option, not a list.

33

[BUG] dnsmasq-full 2.90 freeze in netlink (nftables) — infinite recvmsg(), no crash, no core dump

Firmware: OpenWrt 24.10.5 r29087-d9c5716d1d LuCI openwrt-24.10 branch 25.340.26705~d88390b

dnsmasq version: dnsmasq-full 2.90-r4

Summary

I am experiencing a reproducible issue where dnsmasq does not crash but freezes, stops responding to DNS queries, and stops listening on port 53. The process remains alive (PID exists), but it becomes completely unresponsive.

There is no core dump, because dnsmasq does not receive a fatal signal — it simply hangs.

A watchdog (FAST‑WATCH) detects the freeze and restarts dnsmasq, restoring functionality temporarily.

Symptoms

  • dnsmasq PID stays alive
  • port 53 stops listening
  • DNS queries stop responding
  • no crash, no core dump
  • strace remains attached to the old PID
  • only a restart fixes the issue
  • freeze repeats after some time

Environment

  • OpenWrt 24.10.5 (nftables firewall)
  • dnsmasq-full 2.90-r4
  • nftables is enabled and active
  • no ujail, dnsmasq runs standalone (PPID=1)
    Diagnosis

Using strace -p <pid> -f -tt -s 256, I captured the moment when dnsmasq freezes.

The freeze happens inside netlink while dnsmasq is processing nftables data.

The process enters an infinite recvmsg() loop with NLMSG_MULTI responses:

sendto(5, NLMSG_TYPE=0xa01 / 0xa0a / 0xa09 ...)
recvmsg(5, ...)
recvmsg(5, ...)
recvmsg(5, ...)
...
(infinite)

dnsmasq receives a very large NLMSG_MULTI response from nftables and never exits the loop.

This is a freeze, not a crash.

Key observations

  • dnsmasq repeatedly receives NLMSG_MULTI messages
  • dnsmasq allocates new buffers via mmap()
  • dnsmasq never returns NLMSG_DONE for the second batch
  • dnsmasq stops serving DNS entirely
  • no fatal signal → no core dump

This behavior matches previously reported netlink/nftables freeze bugs, but it still occurs in dnsmasq 2.90.

Expected behavior

dnsmasq should correctly process netlink responses and return to DNS service.

Actual behavior

dnsmasq becomes stuck in netlink processing and stops serving DNS until restarted.

Full strace log

(Insert your full log here inside a code block)

<PASTE YOUR FULL LOG HERE>

Additional notes

  • This issue is reproducible.
  • It happens even with dnsmasq-full 2.90-r4 (latest in OpenWrt).
  • nftables ruleset is standard (OpenWrt default).
  • No custom patches.
  • No jail / procd interference.

Possible root cause

A regression or incomplete fix in dnsmasq’s handling of:

  • NLMSG_MULTI
  • nftables netlink dumps
  • large nftables rulesets
  • multi-part netlink responses

dnsmasq appears to enter an infinite loop while parsing nftables objects.

Temporary workarounds**

  • disable nftset integration in dnsmasq
  • reduce nftables ruleset size
  • restart dnsmasq via watchdog

If needed, I can provide:

  • crash passports
  • system snapshots
  • dnsmasq logs
  • nftables ruleset
  • more strace captures

The link to the dnsmasq_strace.log file has been uploaded to Mega.

34

Thanks for the information. Yes, I’m aware that some netlink‑related issues were addressed in dnsmasq 2.92. However, the freeze I’m experiencing still occurs on dnsmasq‑full 2.90‑r4 (OpenWrt 24.10.5).

This is not a crash — dnsmasq enters an infinite recvmsg() loop while processing nftables netlink messages (NLMSG_MULTI). The process stays alive but stops responding and stops listening on port 53. A watchdog detects the freeze and restarts dnsmasq.

I’ve uploaded the full dnsmasq_strace.log to Mega for analysis. Here is the link: (insert your Mega link here)

If needed, I can also provide crash passports, system snapshots, and nftables ruleset.

35

How about upgrading dnsmasq to 2.92 and see if your config works with that?

36

Thanks for the feedback. Just to clarify: the confdir option is functioning correctly on my system — dnsmasq successfully loads all additional configuration files from /etc/dnsmasq.d . So this part is not related to the issue.

The other two lines ( max_file_limit and bind_dynamic ) are indeed ignored by dnsmasq, but removing them does not change the behavior. They have no effect on runtime operation and therefore cannot influence the freeze.

The problem I’m reporting is not configuration‑related. dnsmasq freezes at runtime inside the netlink/nftables handling path, entering an infinite recvmsg() loop while processing NLMSG_MULTI responses. During the freeze:

  • the process stays alive (no crash, no signal)
  • port 53 stops listening
  • dnsmasq stops responding to queries
  • no core dump is generated
  • only a restart restores functionality

This behavior is fully reproducible and independent of the UCI configuration. The full dnsmasq_strace.log

37

Why not just report it to the dnsmasq author via the mail list (warning, no AI text formatting or emoji or icons allowed on the mailing list):

38

You said you will analyze the core, not run gdb 1h ago. Please reconsider your attitude and get diagnosing YOUR problem. So far there is no indication of reproducibility FROM YOU.

39

I don’t speak English, so I use an AI tool only as a translator.
The text and meaning are mine; the AI only helps me express it in English.

40

I do not speak English, so I use an AI tool only as a translator.
The content and meaning are mine; the AI only helps me express it in English.

Regarding your comment: I am not refusing to diagnose anything. I am trying to provide the information I have, but I am limited by the fact that the crash is not easily reproducible on my side. The core file is the only concrete artifact I currently have, and I am sharing it so that someone more experienced with dnsmasq internals can help interpret it.

I am not asking anyone to run gdb for me. I am asking for guidance on how to interpret the crash and what additional data would be useful to collect. If there are specific steps you want me to perform to improve reproducibility or gather more diagnostics, please tell me and I will follow them.

My intention is to cooperate and provide whatever information is needed, not to shift responsibility.