Unbound/dnsmasq race condition on startup
Open
Nobody has claimed this yet.
bug
- Dominant language
- Makefile
- Stars
- 4.6k
- Forks
- 4k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 134
Description
Package Name
unbound
Maintainer
@EricLuehrsen
OpenWrt Version
24.10.2
OpenWrt Target/Subtarget
x86/64
Steps to Reproduce
- Install unbound
- Configure it for parallel use
- Create extra dnsmasq instances
Actual Behaviour
unbound won't always be able to bind properly to the network interfaces.
I know it's a bit vague, but I've found the problem to be intermittent.
The solution I found was to modify the unbound init script to make it start at 18 instead of 19.
Confirmation Checklist
- The package is maintained in this repository.
- I understand that issues related to the base OpenWrt repository or LuCI repository will be closed.
- I am reporting an issue for OpenWrt, not an unsupported fork.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported setup on OpenWrt 24.10.2 for x86/64: install unbound, enable parallel use, and create extra dnsmasq instances. Inspect the unbound init script and startup ordering, comparing order 19 with the reported workaround of order 18. Done means the services reliably bind to the network interfaces across repeated boots.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100