Web UI and /var/lib/knot-resolver/leases.db mismatch

[barneyklarnocks]

Hi -

(Edited to remove spurious reference to work queue API.)

I’ve long been running IPFire, progressively upgraded over time. I’ve had recurring issues with DNS name resolution within my network breaking periodically for some hosts so I’m delighted by the move to Knot resolver.

This is the version advertised on the main page of my instance: IPFire 2.29 (x86_64) - Core-Update 203.

The update to 203 completed without any errors, but I’ve seen very funky DHCP behaviour since applying the recommended workaround to reload the DHCP configuration. (Nicely summarised at Core Update 203: Recommendations Before and After Upgrading.)

As part of troubleshooting the issue, I’ve compared the list of DHCP leases on the Network > DHCP Server web page and that shown by a SELECT on the /var/lib/knot-resolver/leases.db database file. They don’t match:

Compare with this:

[root@ipfire ~]# DB_PATH="/var/lib/knot-resolver/leases.db"
[root@ipfire ~]# sqlite3 $DB_PATH <<<"select * from leases"
╭───────────────┬──────────────────────────────────────────╮
│    address    │                 hostname                 │
╞═══════════════╪══════════════════════════════════════════╡
│ 192.168.1.110 │ cube.cooley.road.                        │
│ 192.168.1.245 │ spooky-action-at-a-distance.cooley.road. │
│ 192.168.1.3   │ colour-duplex-laser.cooley.road.         │
│ 192.168.1.218 │ media.cooley.road.                       │
│ 192.168.1.207 │ galaxy-s21-5g.cooley.road.               │
│ 192.168.1.139 │ iphone.cooley.road.                      │
│ 192.168.1.2   │ ubnt.cooley.road.                        │
│ 192.168.1.246 │ re305.cooley.road.                       │
╰───────────────┴──────────────────────────────────────────╯
[root@ipfire ~]# 

Compare the address for media.cooley.road, for example. Notice also the list of hosts have some overlap, but aren’t the same.

The upgrade from Core 202 to 203 completed without error: (I’ve removed the log lines for the daily poll; what you see here is what’s logged when executing the upgrade. I see no WARN or ERROR log entries.)

IPFire diagnostics
Section: pakfire
Date: July 22, 2026

17:20:43 pakfire:  PAKFIRE INFO: Pakfire has finished. Closing.
17:20:43 pakfire:  CORE INFO: core-list.db is 308 seconds old. - DEBUG: noforce
17:20:43 pakfire:  DB INFO: packages_list.db is 309 seconds old. - DEBUG: noforce
17:20:43 pakfire:  MIRROR INFO: server-list.db is 310 seconds old. - DEBUG: noforce
17:20:43 pakfire:  PAKFIRE INFO: IPFire Pakfire 2.29-x86_64 started!
17:17:09 pakfire:  PAKFIRE INFO: Pakfire has finished. Closing.
17:17:09 pakfire:  PAKFIRE WARN: No new package upgrades available.
17:17:09 pakfire:  DB INFO: packages_list.db is 95 seconds old. - DEBUG: noforce
17:17:09 pakfire:  PAKFIRE INFO: Checking for package updates...
17:17:09 pakfire:  PAKFIRE UPGR: core-upgrade-203: Finished.
17:17:09 pakfire:  CLEANUP: tmp
17:15:48 pakfire:  PAKFIRE UPGR: core-upgrade-203: Upgrading files and running post-upgrading scripts...
17:15:48 pakfire:  DECRYPT FINISHED: core-upgrade-203 - Status: 0
17:15:47 pakfire:  DECRYPT STARTED: core-upgrade-203
17:15:47 pakfire:  CLEANUP: tmp
17:15:47 pakfire:  PAKFIRE UPGR: core-upgrade-203: Decrypting...
17:15:47 pakfire:  DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-203.ipfire
17:15:47 pakfire:  DOWNLOAD INFO: Signature of core-upgrade-2.29-203.ipfire is fine.
17:15:46 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
17:15:46 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
17:15:42 pakfire:  DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-203.ipfire has size of 50941231 bytes
17:15:42 pakfire:  DOWNLOAD INFO: Host: mirrors.dotsrc.org (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/paks/core-upgrade-2.29-203.ipfire
17:15:42 pakfire:  MIRROR INFO: 18 servers found in list
17:15:42 pakfire:  DOWNLOAD STARTED: paks/core-upgrade-2.29-203.ipfire
17:15:42 pakfire:  DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/meta/meta-core-upgrade-203
17:15:42 pakfire:  DOWNLOAD INFO: Signature of meta-core-upgrade-203 is fine.
17:15:42 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
17:15:42 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
17:15:42 pakfire:  DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/meta/meta-core-upgrade-203 has size of 1040 bytes
17:15:41 pakfire:  DOWNLOAD INFO: Host: mirror.marwan.ma (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/meta/meta-core-upgrade-203
17:15:41 pakfire:  MIRROR INFO: 18 servers found in list
17:15:41 pakfire:  DOWNLOAD STARTED: meta/meta-core-upgrade-203
17:15:41 pakfire:  CORE UPGR: Upgrading from release 202 to 203
17:15:41 pakfire:  CORE INFO: core-list.db is 6 seconds old. - DEBUG: noforce
17:15:41 pakfire:  CORE INFO: Checking for Core-Updates...
17:15:41 pakfire:  PAKFIRE INFO: IPFire Pakfire 2.29-x86_64 started!
17:15:35 pakfire:  PAKFIRE INFO: Pakfire has finished. Closing.
17:15:35 pakfire:  DOWNLOAD FINISHED: pub/ipfire/pakfire2/2.29-x86_64/lists/core-list.db
17:15:35 pakfire:  DOWNLOAD INFO: Signature of core-list.db is fine.
17:15:35 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
17:15:35 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
17:15:34 pakfire:  DOWNLOAD INFO: pub/ipfire/pakfire2/2.29-x86_64/lists/core-list.db has size of 903 bytes
17:15:34 pakfire:  DOWNLOAD INFO: Host: mirror.datacenter.by (HTTPS) - File: pub/ipfire/pakfire2/2.29-x86_64/lists/core-list.db
17:15:34 pakfire:  MIRROR INFO: 18 servers found in list
17:15:34 pakfire:  DOWNLOAD STARTED: lists/core-list.db
17:15:34 pakfire:  CORE INFO: core-list.db is 56647 seconds old. - DEBUG: force
17:15:34 pakfire:  DOWNLOAD FINISHED: ipfire/pakfire2/2.29-x86_64/lists/packages_list.db
17:15:34 pakfire:  DOWNLOAD INFO: Signature of packages_list.db is fine.
17:15:34 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
17:15:34 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
17:15:33 pakfire:  DOWNLOAD INFO: ipfire/pakfire2/2.29-x86_64/lists/packages_list.db has size of 4919 bytes
17:15:33 pakfire:  DOWNLOAD INFO: Host: mirrors.dotsrc.org (HTTPS) - File: ipfire/pakfire2/2.29-x86_64/lists/packages_list.db
17:15:33 pakfire:  MIRROR INFO: 18 servers found in list
17:15:33 pakfire:  DOWNLOAD STARTED: lists/packages_list.db
17:15:33 pakfire:  DB INFO: packages_list.db is 56647 seconds old. - DEBUG: force
17:15:33 pakfire:  DOWNLOAD FINISHED: 2.29-x86_64/lists/server-list.db
17:15:33 pakfire:  DOWNLOAD INFO: Signature of server-list.db is fine.
17:15:33 pakfire:  DOWNLOAD INFO: File received. Start checking signature...
17:15:33 pakfire:  DOWNLOAD INFO: HTTP-Status-Code: 200 - 200 OK
17:15:33 pakfire:  DOWNLOAD INFO: 2.29-x86_64/lists/server-list.db has size of 1915 bytes
17:15:32 pakfire:  DOWNLOAD INFO: Host: pakfire.ipfire.org (HTTPS) - File: 2.29-x86_64/lists/server-list.db
17:15:32 pakfire:  DOWNLOAD STARTED: 2.29-x86_64/lists/server-list.db
17:15:32 pakfire:  MIRROR INFO: server-list.db is 56647 seconds old. - DEBUG: force
17:15:32 pakfire:  PAKFIRE INFO: IPFire Pakfire 2.29-x86_64 started!

Of course I restarted IPFire after the upgrade:

[root@ipfire ~]# uptime
 14:59:58 up 3 days, 21:41,  2 users,  load average: 0.08, 0.16, 0.09

…and:

IPFire diagnostics
Section: ipfire
Date: July 22, 2026

17:17:23 ipfire:  Rebooting IPFire
01:15:08 ipfire:  NTP synchronisation event

Thanks for your help!

[hvacguy (Shaun HVAC)]

As noted here.

The DNS lease bridge is not working on the DHCP page.

Must use Edit hosts page

@pscar13

• Go to Network → DHCP Server and create or edit the fixed lease (assign the IP address to the device’s MAC address). The Remark field can still be used for documentation, but it is no longer used as the local DNS hostname.
• Then go to Network → Edit Hosts and add the desired hostname for that IP address.

[barneyklarnocks]

Thank you for the quick reply.

The problematic hosts are not the ones with the fixed leases.

How can you account for the two different IP addresses assigned for the host media.cooley.road?

What am I looking at in the response from pgrep?

[pscar13]

@barneyklarnocks

pgrep -alf unbound

The kworker processes are not related to Unbound.

They are Linux kernel worker threads that handle various asynchronous tasks in the background.

@barneyklarnocks

How can you account for the two different IP addresses assigned for the host media.cooley.road?

I am actually glad to see that I’m not the only one experiencing issues with leases.db.

I tried to explain this here, but at the time it seemed that I was the only person affected:

CU 203 Test : DNS does not update DHCP leases

I do not believe that RFC 2136 defines which hostname should be registered in the local DNS. However, the way CU203 handles DNS for the local network is completely different from CU202. I explained how CU202 works here. Based on what I observed for CU203 regarding knot-resolver At startup 1 - It loads the addresses defined in the /etc/hosts and /var/ipfire/main/hosts files into its local cache. Then When a host connects via DHCP, it adds its address and client hostname in other lease.db …

From my observations, the first IP address recorded for a hostname persists in the database, even if that hostname later receives a different IP address.

The entry is only removed when the DHCP lease is released or expires. However, this does not always happen, so the stale record can remain in leases.db indefinitely unless it is removed manually.

[barneyklarnocks]

@pscar13

From my observations, the first IP address recorded for a hostname persists in the database, even if that hostname later receives a different IP address.

The entry is only removed when the DHCP lease is released or expires. However, this does not always happen, so the stale record can remain in leases.db indefinitely unless it is removed manually.

Thank you for your reply.

I’m glad to know that the kworker tasks are unrelated to unbound.

I do think there’s more going on, but I can’t put my finger on it yet.

I’m going to keep a close eye on this because I still don’t have an explanation for how the list of hosts on the DHCP Configuration page can differ so much from the contents of /var/lib/knot-resolver/leases.db.

For the record, here’s how to view, add and remove DHCP entries in the SQLite database using the dhcp-lease bash script:

View the existing records

DB_PATH="/var/lib/knot-resolver/leases.db"
sqlite3 $DB_PATH <<<"select * from leases"

Add a record

/usr/sbin/dhcp-lease commit ADDRESS=<IP address> HOSTNAME=<hostname> DOMAINNAME=<domain name>

For example:

/usr/sbin/dhcp-lease commit ADDRESS=192.168.1.247 HOSTNAME=media DOMAINNAME=cooley.road

Delete a record

/usr/sbin/dhcp-lease release ADDRESS=192.168.1.247

[pscar13]

Thanks for looking into this.

Once the problem is clearly identified, it would be worth filing a bug report.

My previous reports on Bugzilla haven’t been very successful.
So, I’d rather leave that task to someone who is better at writing bug reports than I am.

[barneyklarnocks]

Thanks. I do have experience writing bug reports, but not for this project.

I’ll remove the red-herring reference to the workqueue API which I’d confused with still-running unbound processes.

[pscar13]

@barneyklarnocks

I’ll remove the red-herring reference to the workqueue API which I’d confused with still-running unbound processes.

You could have left the reference to kworker events_unbound.
It’s an easy mistake to make, and other users might have the same question.
There was nothing wrong with asking.

[barneyklarnocks]

Thanks. It’s still referenced tangentially here in the thread anyway.

[barneyklarnocks]

I’ve logged the issue 14031 – Web UI and /var/lib/knot-resolver/leases.db mismatch