Modify the loadproc line 46 in /etc/init.d/dhcp and add -v next to -d
Now the arguments are >=2 so the loglevel becomes debug (see line 580)
I switched on the e6500 laptop. the laptop got a .27
Here’s the log file (the error may mean something).
Oct 17 07:56:47 ipfire dhcpd: DHCPOFFER on 10.0.0.27 to c4:46:19:50:47:ac (e6500) via green0
Oct 17 07:56:47 ipfire dhcpd: DHCPREQUEST for 10.0.0.27 (10.0.0.1) from c4:46:19:50:47:ac (e6500) via green0
Oct 17 07:56:47 ipfire dhcpd: DHCPACK on 10.0.0.27 to c4:46:19:50:47:ac (e6500) via green0
Oct 17 07:57:27 ipfire unbound: [26317:0] info: 10.0.0.36 e6500.lan. A IN
Oct 17 07:57:27 ipfire unbound: [26317:0] info: 10.0.0.36 e6500.lan. AAAA IN
Oct 17 07:59:24 ipfire dhcp[26769]: Could not run unbound-control local_data e6500.lan 60 IN A 10.0.0.27, error code: 1: b''
Oct 17 08:04:16 ipfire dhcpd: DHCPREQUEST for 10.0.0.27 from c4:46:19:50:47:ac (e6500) via green0
Oct 17 08:04:16 ipfire dhcpd: DHCPACK on 10.0.0.27 to c4:46:19:50:47:ac (e6500) via green0
Adding to the puzzle … the error says local_data (note the underscore) but if you look at the unbound file (/etc/unbound/dhcp-leases.conf) it says, local-data (note the dash)
Oct 18 15:28:03 ipfire dhcp[31438]: Adding new record main.lan 60 IN A 10.0.0.47
Oct 18 15:28:03 ipfire dhcp[31438]: Adding new record 47.0.0.10.in-addr.arpa 60 IN PTR main.lan
About line 514 local_data … see line 530 local-data
well, thx to pauls hint with: /usr/sbin/unbound-dhcp-leases-bridge -d -vv
i was able to get the local dns working again.
this struck my ipfire mini after the last coreupdate…
it seems the unbound-dhcp-leases-bridge startup on booting
the mini is not reliable…
I don’t think this is a configuration issue. The bridge gets started, and works occasionally, but it seems to miss some events that should cause it to update DNS. That sounds more like a real bug (and I suspect it has something to do with how inotify events are being handled and rearmed).
FYI: for those using my 3 line script to reset dhcp and unbound, add a sleep 3 before unbound. Ipfire needs time to breathe and without the sleep 3, it may throw some errors in /var/log/messages.
unbound-dhcp-leases-bridge has received improvements to reliably propagate DHCP hosts to the DNS. Thanks go to Anthony Heading for his work on that front.
Follow up question: I start the dhcp-leases-bridge with -d -vv /usr/bin/python3 /usr/sbin/unbound-dhcp-leases-bridge -d -vv
The text “Wakeup of main loop” shows in /var/log/messages at uneven times, sometimes 30s, other times 18s, or 1m 30s. There does not seem to be a pattern. Here’s some log …
Apr 12 05:46:44 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:47:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:48:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:48:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:50:02 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:50:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:51:51 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:53:21 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:54:21 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:03 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:09 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:51 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:55:57 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:56:02 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:57:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 05:58:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:14 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:38 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:00:43 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:25 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:31 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:01:37 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:13 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:31 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:03:49 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:05:19 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:20 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:26 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:32 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:50 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:06:56 zotac dhcp[16447]: Wakeup of main loop
Apr 12 06:07:02 zotac dhcp[16447]: Wakeup of main loop
Yes, the DHCP → DNS propagation in core 167 update seems to do the right thing now. This is an intermittent problem though, so it probably needs a bit longer before we declare victory, but the early indications are good. Thanks!