- Status New
- Percent Complete
- Task Type Bug Report
- Category Base system
- Assigned To No-one
- Operating System All
- Severity Low
- Priority Medium
- Reported Version Trunk
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: OpenWrt/LEDE Project
Opened by Daniel Golle - 17.08.2016
Last edited by Ted Hess - 08.09.2016
Opened by Daniel Golle - 17.08.2016
Last edited by Ted Hess - 08.09.2016
FS#97 - dnsmasq doesn't receive updated dns servers when running inside ujail
Bind-mounting /tmp/resolv.conf.auto apparently doesn’t forward inotify events arriving from the kernel when resolv.conf.auto was changed (e.g. upstream DNS servers were received by a DHCP client or pppd). Restarting dnsmasq or running it without ujail solves the issue.
Hi Daniel,
can you check if the inode number of /tmp/resolv.conf.auto change when such events happen
(ls -i /tmp/resolv.conf.auto)
Yes, apparently it does.
root@test:~# ls -i /tmp/resolv.conf.auto
root@test:~# /etc/init.d/network restart
root@test:~# ls -i /tmp/resolv.conf.auto
root@test:~#
Hi Daniel,
It's one of the limitations of bind mounts, what you see in the jail is the file with inode 3400 and never the one with inode 3897, because what you really changed is /tmp
There is 2 workarounds:
1) write to the file instead of replacing it with a new one (with mv/rename). With this option you loose the atomicity of the rename
2) bind mount the parent dir of the file, bind mouting /tmp is not a good idea but maybe you can move resolv.conf.auto in a dnsmasq dir
May I propose that netifd write not to /tmp/resolv.conf.auto but to /tmp/netifd/resolv.conf or similar, so that /tmp/netifd can be mounted into the jail as a directory and inotify will work?