Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 594
    • Issues 594
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 61
    • Merge requests 61
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • KeaKea
  • Issues
  • #1382
Closed
Open
Issue created Aug 13, 2020 by Marcin Siodelski@marcinDeveloper

Kea Config Backend fails to fetch the data from the database on MariaDB 10.4.14

When the server with CB is started, it tries to fetch all audit entries and the corresponding data from the database to update the runtime configuration. Because this mechanism generic, i.e. can also fetch further incremental changes it uses a moving timestamp value from which it considers that the data are new. This timestamp is initially set to January 1st 1970. The problem is that is that MySQL's lowest possible timestamp is January 1st 1970 at 00:00:01 UTC. In addition, the date we're using as an input to the query is time zone dependent, because MySQL consumes data in local time and converts to UTC. So, it is not that we're off by 1 second with the lowest timestamp we use as input to MySQL, but we may be off by a couple of hours if we live in a distant timezone.

Earlier MySQL versions we have tested are not sensitive to this and seem to work fine. The issue was first found on MariaDB 10.4.13 and also reproduced by myself on MariaDB 10.4.14. I applied local changes to the code to set the initial timestamp to 1980-01-01 and the whole thing worked fine. I did another similar experiment and set the initial date to 1970-01-02, which is within the range of all possible timezones and it worked too. This seems to confirm the theory about CB using out of range value. I'd suggest that we maybe simply set this date to 2000-01-01 and not bother...

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking