Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Incomplete
-
10.9.1
-
None
-
Ubuntu 22.04
Using apt packages:
mariadb-server 1:10.9.1+maria~jammy
mariadb-plugin-hashicorp-key-management 1:10.9.1+maria~jammy
Vault v1.11.2
Description
Hi,
during evaluation of the Hashicorp Plugin I tested the behaviour if vault provides a wrong encryption key.
This could result by a wrong mariadb configuration or some other inconsistencies...
Expected Behaviour: Proper Error message in mariadb error log.
Current Behaviour:
2022-08-03 19:27:37 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
|
2022-08-03 19:27:37 0 [Note] InnoDB: Number of transaction pools: 1
|
2022-08-03 19:27:37 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
|
2022-08-03 19:27:37 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
|
2022-08-03 19:27:37 0 [Note] InnoDB: Completed initialization of buffer pool
|
2022-08-03 19:27:37 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
|
2022-08-03 19:27:37 0 [ERROR] InnoDB: Cannot decrypt [page id: space=0, page number=7]
|
2022-08-03 19:27:37 0 [ERROR] InnoDB: Cannot decrypt [page id: space=0, page number=7]
|
2022-08-03 19:27:37 0 [ERROR] InnoDB: Cannot decrypt [page id: space=0, page number=7]
|
2022-08-03 19:27:37 0 [ERROR] InnoDB: Cannot decrypt [page id: space=0, page number=7]
|
2022-08-03 19:27:37 0 [ERROR] InnoDB: Cannot decrypt [page id: space=0, page number=7]
|
(many multiple log lines)
|
|
220803 19:27:37 [ERROR] mysqld got signal 11 ;
|
This could be because you hit a bug. It is also possible that this binary
|
or one of the libraries it was linked against is corrupt, improperly built,
|
or misconfigured. This error can also be caused by malfunctioning hardware.
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
|
|
We will try our best to scrape up some info that will hopefully help
|
diagnose the problem, but since we have already crashed,
|
something is definitely wrong and this may fail.
|
|
Server version: 10.9.1-MariaDB-1:10.9.1+maria~jammy
|
key_buffer_size=134217728
|
read_buffer_size=131072
|
max_used_connections=0
|
max_threads=153
|
thread_count=0
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467999 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
Thread pointer: 0x0
|
Attempting backtrace. You can use the following information to find out
|
where mysqld died. If you see no messages after this, something went
|
terribly wrong...
|
stack_bottom = 0x0 thread_stack 0x49000
|
??:0(my_print_stacktrace)[0x561ba69966f2]
|
??:0(handle_fatal_signal)[0x561ba6469678]
|
??:0(__sigaction)[0x7fbb2f790520]
|
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x561ba689fd0c]
|
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x561ba60918e1]
|
??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const*))[0x561ba6752f89]
|
??:0(ha_initialize_handlerton(st_plugin_int*))[0x561ba646c482]
|
??:0(sys_var_pluginvar::sys_var_pluginvar(sys_var_chain*, char const*, st_plugin_int*, st_mysql_sys_var*, char const*))[0x561ba62362f6]
|
??:0(plugin_init(int*, char**, int))[0x561ba62374cd]
|
??:0(unireg_abort)[0x561ba610e7a1]
|
??:0(mysqld_main(int, char**))[0x561ba6113fb4]
|
??:0(__libc_init_first)[0x7fbb2f777d90]
|
??:0(__libc_start_main)[0x7fbb2f777e40]
|
??:0(_start)[0x561ba6108a85]
|
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
|
information that should help you find out what is causing the crash.
|
Writing a core file...
|
Working directory at /var/lib/mysql
|
Resource Limits:
|
Limit Soft Limit Hard Limit Units
|
Max cpu time unlimited unlimited seconds
|
Max file size unlimited unlimited bytes
|
Max data size unlimited unlimited bytes
|
Max stack size 8388608 unlimited bytes
|
Max core file size 0 unlimited bytes
|
Max resident set unlimited unlimited bytes
|
Max processes 15550 15550 processes
|
Max open files 32768 32768 files
|
Max locked memory 524288 524288 bytes
|
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 15550 15550 signals
|
Max msgqueue size 819200 819200 bytes
|
Max nice priority 0 0
|
Max realtime priority 0 0
|
Max realtime timeout unlimited unlimited us
|
Core pattern: |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E
|
So as a user I can not see if my vault just provides a wrong encryption key or if there is some other error like corrupted database files.
If there is a possibility to detect a wrong encryption key, it should result in a according error log message.