Closed FelixJacobi closed 2 years ago
Only one of my servers seems to be affected. Should I send the SQLite database?
Was this server upgraded or is it a new instance with new database file?
Yes, sending the database file might help debugging this issue.
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.
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... :-(
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).
Same problem exists for CentOS/RedHat but should be fixed with latest workaround commit.
Should be fixed in 1.0.9
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.
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?
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.
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?
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.
Just saw this in the logs:
I am not sure if this was introduced with one of the recent releases, but I never saw that before.