Prepared statement needs to be re-prepared
Describe the bug This probably doesn't qualify as a Kea bug, but I thought it might be worth asking about. We are running 2 kea servers with a shared MySQL (MariaDB) backend. We recently upgraded from MariaDB 10.3 to MariaDB 10.5.
We replaced the hosts
table with a hosts_history
TABLE (added a deleted_at
column to allow for keeping host history) and a hosts
VIEW that only shows non-deleted items. This has been working for us for many years.
Everything seems to work for a while until randomly, we start getting errors for systems with host reservations.
The error in the log is:
2023-08-14 18:52:59.613 DEBUG [kea-dhcp4.bad-packets/169655.139690552555648] DHCP4_PACKET_DROP_0007 [hwtype=1 xx:xx:xx:xx:xx:17], cid=[no info], tid=0xee1b36c3
: failed to process packet: unable to execute for <SELECT h.host_id, h.dhcp_identifier, h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id, h.ipv4_address, h.hostname, h.dhcp4_client_classes, h.dhcp6_client_classes, h.us
er_context, h.dhcp4_next_server, h.dhcp4_server_hostname, h.dhcp4_boot_file_name, h.auth_key, o.option_id, o.code, o.value, o.formatted_value, o.space, o.persistent, o.user_context FROM hosts AS h LEFT JOIN dhcp4_options AS o ON h
.host_id = o.host_id WHERE h.dhcp4_subnet_id = ? AND h.dhcp_identifier_type = ? AND h.dhcp_identifier = ? ORDER BY h.host_id, o.option_id>, reason: Prepared statement needs to be re-prepared (error code 1615)
When this happens, the host making the request gets no response, not even an error. (Similar to #281 (closed)?)
It is not clear exactly how to reproduce this error. We even created a completely new copy of the database using kea-admin
and it ran fine for just less than 24 hours before stopping with the same error.
To Reproduce Steps to reproduce the behavior:
- Create a MySQL database. Rename the
hosts
table tohosts_history
and create a VIEW forhosts
:CREATE VIEW `hosts` AS select distinct `hosts_history`.`host_id` AS `host_id`, `hosts_history`.`dhcp_identifier` AS `dhcp_identifier`,`hosts_history`.`dhcp_identifier_type` AS `dhcp_identifier_type`, `hosts_history`.`dhcp4_subnet_id` AS `dhcp4_subnet_id`,`hosts_history`.`dhcp6_subnet_id` AS `dhcp6_subnet_id`, `hosts_history`.`ipv4_address` AS `ipv4_address`,`hosts_history`.`hostname` AS `hostname`,`hosts_history`.`dhcp4_client_classes` AS `dhcp4_client_classes`, `hosts_history`.`dhcp6_client_classes` AS `dhcp6_client_classes`,`hosts_history`.`dhcp4_next_server` AS `dhcp4_next_server`, `hosts_history`.`dhcp4_server_hostname` AS `dhcp4_server_hostname`,`hosts_history`.`dhcp4_boot_file_name` AS `dhcp4_boot_file_name`, `hosts_history`.`user_context` AS `user_context`,`hosts_history`.`auth_key` AS `auth_key` from `hosts_history` where `hosts_history`.`deleted` IS NULL
- Run Kea dhcp4 with standard mysql configuration
- The client uses the standard linux dhclient or the Nagios
check_dhcp
plugin. - The server usually send standard responses except sometimes when it logs this error and sends no response.
Expected behavior
- Valid responses should always be sent
- An error should be sent back to the client when there is a server error.
Environment:
- Kea version: Supplied from RHEL9 EPEL respository
# kea-dhcp4 -V 2.2.0 tarball linked with: log4cplus 2.0.5 OpenSSL 3.0.7 1 Nov 2022 database: MySQL backend 14.0, library 3.2.6 PostgreSQL backend 13.0, library 130011 Memfile backend 2.1
- OS: RHEL 9.2