Error: no such table: leases

[FelixJacobi]

Just saw this in the logs:

Okt 31 21:49:33 iserv.stsbl.de dhcpy6d[1921388]: Error: no such table: leases
Okt 31 21:49:33 iserv.stsbl.de dhcpy6d[1921388]: Query: DELETE FROM leases WHERE active = 0 AND category = 'random' AND valid_until < '1635707340'

I am not sure if this was introduced with one of the recent releases, but I never saw that before.

[FelixJacobi]

Only one of my servers seems to be affected. Should I send the SQLite database?

[HenriWahl]

Was this server upgraded or is it a new instance with new database file?

Yes, sending the database file might help debugging this issue.

[FelixJacobi]

Was this server upgraded or is it a new instance with new database file?

Upgraded, it's still the same, which was affected by the previous meta table error.

Yes, sending the database file might help debugging this issue.

Will do.

[HenriWahl]

I set up a new instance and found as expected all tables available and working. Apparently something went wrong with the update. The fun part is that the table exists in your sqlite file too... :-(

[FelixJacobi]

I guess, I found the origin of the issue. The issue encountered again:

Nov  1 17:21:16 router dhcpy6d[132798]: Query: DELETE FROM leases WHERE active = 0 AND category = 'random' AND valid_until < '1635731675'
Nov  1 17:21:16 router dhcpy6d[132798]: Error: no such table: leases 

As I was working on the machine just-in-time, I copied the database:

felix.jacobi@felix ~ % scp root@router.stsbl.de:/var/lib/dhcpy6d/volatile.sqlite /tmp
volatile.sqlite                                   100%    0     0.0KB/s   00:00
felix.jacobi@felix ~ % sqlite3 /tmp/volatile.sqlite
SQLite version 3.35.5 2021-04-19 18:32:05

Enter ".help" for usage hints.

sqlite> SELECT * FROM leases;
Error: no such table: leases
sqlite>
felix.jacobi@felix ~ % file /tmp/volatile.sqlite
/tmp/volatile.sqlite: empty

felix.jacobi@felix ~ % cat /tmp/volatile.sqlite
felix.jacobi@felix ~ % 

It's an empty file. I think, that this is caused by the fact, that an empty file is delivered in the Debian package:

router.stsbl.de ~ # dpkg -S /var/lib/dhcpy6d/volatile.sqlite
dhcpy6d: /var/lib/dhcpy6d/volatile.sqlite 

This causes the issue coming into place when the package is updated. My proposal would be to move the database out the package (as it is variable data anyway) and create it on a sufficient point (e.g. maintainer script or somewhere on startup).

[HenriWahl]

Same problem exists for CentOS/RedHat but should be fixed with latest workaround commit.

[HenriWahl]

Should be fixed in 1.0.9

[FelixJacobi]

Sorry, for late reply!

Works fine for me, I guess. The only problem left, is that /var/lib/dhcpy6d/volatile.sqlite is now removed on upgrading as it was part of the package before. But in my opinion it's not worth to handle that, because it would be hard to circumvent dpkg here. I will restart dhcpy6d on deploying to circumvent that.

[HenriWahl]

The only problem left, is that /var/lib/dhcpy6d/volatile.sqlite is now removed on upgrading as it was part of the package before.

Well, should not be removed either. Strange, because it explicitly only gets touched... the DB file really is lost and replaced by an empty one?

[FelixJacobi]

It's because dpkg tracked the file as part of the package. If a file is no longer contained in the new package, it will be automatically removed on unpacking an upgrade.

What could work: Add a debian/preinst script (which runs before unpacking) which mv's the database away to a well-known other location (e.g. /var/lib/dhcpy6d/volatile.sqlite-upgrade) and move it back in the postinst script when it exist.

But I am not sure if it is worth it.

[HenriWahl]

This should happen when upgrading to the 1.0.9 but not for the next versions, because it then won't be part of the package anymore, right?

[FelixJacobi]

This should happen when upgrading to the 1.0.9 but not for the next versions, because it then won't be part of the package anymore, right?

Yes.