2025-04-07  0:12:27 139740124804864 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 00:12:27 7f17c87ff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  0:12:27 139740124804864 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  0:12:27 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=42
max_threads=1002
thread_count=42
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55f7edc5b6ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x55f7ed821cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f17ee396980]
linux/raise.c:51(__GI_raise)[0x7f17ed626e87]
stdlib/abort.c:81(__GI_abort)[0x7f17ed6287f1]
/usr/sbin/mysqld(+0x836621)[0x55f7edac0621]
/usr/sbin/mysqld(+0x8378dd)[0x55f7edac18dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55f7edbe49c3]
/usr/sbin/mysqld(+0x95ab27)[0x55f7edbe4b27]
/usr/sbin/mysqld(+0x9102fc)[0x55f7edb9a2fc]
/usr/sbin/mysqld(+0x91766b)[0x55f7edba166b]
/usr/sbin/mysqld(+0x9189b2)[0x55f7edba29b2]
nptl/pthread_create.c:463(start_thread)[0x7f17ee38b6db]
x86_64/clone.S:97(clone)[0x7f17ed70961f]
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.
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Using Linux native AIO
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  0:12:35 139752323562624 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  0:12:36 139752323562624 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15742883852
2025-04-07  0:12:39 139752323562624 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 102650880
2025-04-07  0:12:40 139752323562624 [Note] InnoDB: Starting final batch to recover 9 pages from redo log
2025-04-07  0:12:41 139752323562624 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  0:12:41 139751755605760 [Note] InnoDB: Starting in background the rollback of recovered transactions
2025-04-07  0:12:41 139752323562624 [Note] InnoDB: Waiting for purge to start
2025-04-07  0:12:41 139752323562624 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15742889970
2025-04-07  0:12:41 139751755605760 [Note] InnoDB: Rollback of trx with id 102650578 completed
2025-04-07  0:12:41 139751755605760 [Note] InnoDB: Rollback of non-prepared transactions completed
2025-04-07  0:15:42 139752323562624 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 00:15:42 7f1a9f9a3c80  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  0:15:42 139752323562624 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  0:15:42 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=1002
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5632229bb6ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x563222581cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f1a9e889980]
linux/raise.c:51(__GI_raise)[0x7f1a9db19e87]
stdlib/abort.c:81(__GI_abort)[0x7f1a9db1b7f1]
/usr/sbin/mysqld(+0x836621)[0x563222820621]
/usr/sbin/mysqld(+0x8378dd)[0x5632228218dd]
/usr/sbin/mysqld(+0x95a9c3)[0x5632229449c3]
/usr/sbin/mysqld(+0x95ab27)[0x563222944b27]
/usr/sbin/mysqld(+0x9102fc)[0x5632228fa2fc]
/usr/sbin/mysqld(+0x91766b)[0x56322290166b]
/usr/sbin/mysqld(+0x81499d)[0x5632227fe99d]
/usr/sbin/mysqld(+0x819758)[0x563222803758]
/usr/sbin/mysqld(+0x8ab7eb)[0x5632228957eb]
/usr/sbin/mysqld(+0x7e048e)[0x5632227ca48e]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x62)[0x563222584252]
/usr/sbin/mysqld(+0x42a792)[0x563222414792]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x78a)[0x5632224156ba]
/usr/sbin/mysqld(+0x3827e7)[0x56322236c7e7]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x4aa)[0x563222371fda]
csu/libc-start.c:344(__libc_start_main)[0x7f1a9dafcc87]
/usr/sbin/mysqld(_start+0x2a)[0x56322236624a]
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.
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Using Linux native AIO
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15742883852
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-04-07  0:15:48 140513607732352 [Note] InnoDB: Starting final batch to recover 10 pages from redo log
2025-04-07  0:15:49 140513607732352 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  0:15:49 140513607732352 [Note] InnoDB: Waiting for purge to start
2025-04-07  0:15:49 140513607732352 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15742890076
2025-04-07  0:17:25 140513607732352 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  0:17:25 140512925316864 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  0:17:25 140513607732352 [Note] Recovering after a crash using tc.log
2025-04-07  0:17:25 140513607732352 [Note] Starting crash recovery...
2025-04-07  0:17:25 140513607732352 [Note] Crash recovery finished.
2025-04-07  0:17:25 140513607732352 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  0:17:25 140513607732352 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  1:03:08 140512954676992 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 01:03:08 7fcbb8bff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  1:03:08 140512954676992 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  1:03:08 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=48
max_threads=1002
thread_count=29
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55d877ea46ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x55d877a6acfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7fcbde9b2980]
linux/raise.c:51(__GI_raise)[0x7fcbddc42e87]
stdlib/abort.c:81(__GI_abort)[0x7fcbddc447f1]
/usr/sbin/mysqld(+0x836621)[0x55d877d09621]
/usr/sbin/mysqld(+0x8378dd)[0x55d877d0a8dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55d877e2d9c3]
/usr/sbin/mysqld(+0x95ab27)[0x55d877e2db27]
/usr/sbin/mysqld(+0x9102fc)[0x55d877de32fc]
/usr/sbin/mysqld(+0x91766b)[0x55d877dea66b]
/usr/sbin/mysqld(+0x9189b2)[0x55d877deb9b2]
nptl/pthread_create.c:463(start_thread)[0x7fcbde9a76db]
x86_64/clone.S:97(clone)[0x7fcbddd2561f]
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.
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Using Linux native AIO
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15743033884
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-04-07  1:03:14 139908028857472 [Note] InnoDB: Starting final batch to recover 5 pages from redo log
2025-04-07  1:03:15 139908028857472 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  1:03:15 139908028857472 [Note] InnoDB: Waiting for purge to start
2025-04-07  1:03:15 139908028857472 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15743034264
2025-04-07  1:03:15 139907347511040 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  1:03:15 139908028857472 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  1:03:15 139908028857472 [Note] Recovering after a crash using tc.log
2025-04-07  1:03:15 139908028857472 [Note] Starting crash recovery...
2025-04-07  1:03:15 139908028857472 [Note] Crash recovery finished.
2025-04-07  1:03:15 139908028857472 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  1:03:15 139908028857472 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  1:15:27 139907376871168 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 01:15:27 7f3eb97ff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  1:15:27 139907376871168 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  1:15:27 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=23
max_threads=1002
thread_count=23
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55a6392316ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x55a638df7cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f3edf4ad980]
linux/raise.c:51(__GI_raise)[0x7f3ede73de87]
stdlib/abort.c:81(__GI_abort)[0x7f3ede73f7f1]
/usr/sbin/mysqld(+0x836621)[0x55a639096621]
/usr/sbin/mysqld(+0x8378dd)[0x55a6390978dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55a6391ba9c3]
/usr/sbin/mysqld(+0x95ab27)[0x55a6391bab27]
/usr/sbin/mysqld(+0x9102fc)[0x55a6391702fc]
/usr/sbin/mysqld(+0x91766b)[0x55a63917766b]
/usr/sbin/mysqld(+0x9189b2)[0x55a6391789b2]
nptl/pthread_create.c:463(start_thread)[0x7f3edf4a26db]
x86_64/clone.S:97(clone)[0x7f3ede82061f]
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.
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Using Linux native AIO
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15743067459
2025-04-07  1:15:32 140223827524736 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 102658048
2025-04-07  1:15:33 140223827524736 [Note] InnoDB: Starting final batch to recover 17 pages from redo log
2025-04-07  1:15:33 140223827524736 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  1:15:33 140223262484224 [Note] InnoDB: Starting in background the rollback of recovered transactions
2025-04-07  1:15:33 140223827524736 [Note] InnoDB: Waiting for purge to start
2025-04-07  1:15:33 140223827524736 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15743080692
2025-04-07  1:15:33 140223262484224 [Note] InnoDB: Rollback of trx with id 102657758 completed
2025-04-07  1:15:33 140223262484224 [Note] InnoDB: Rollback of non-prepared transactions completed
2025-04-07  1:16:20 140223262484224 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  1:16:20 140223827524736 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  1:16:20 140223827524736 [Note] Recovering after a crash using tc.log
2025-04-07  1:16:20 140223827524736 [Note] Starting crash recovery...
2025-04-07  1:16:20 140223827524736 [Note] Crash recovery finished.
2025-04-07  1:16:20 140223827524736 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  1:16:20 140223827524736 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  2:30:52 140223161825024 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 02:30:52 7f883fbff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  2:30:52 140223161825024 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  2:30:52 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=26
max_threads=1002
thread_count=26
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x557e05f926ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x557e05b58cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f88665c1980]
linux/raise.c:51(__GI_raise)[0x7f8865851e87]
stdlib/abort.c:81(__GI_abort)[0x7f88658537f1]
/usr/sbin/mysqld(+0x836621)[0x557e05df7621]
/usr/sbin/mysqld(+0x8378dd)[0x557e05df88dd]
/usr/sbin/mysqld(+0x95a9c3)[0x557e05f1b9c3]
/usr/sbin/mysqld(+0x95ab27)[0x557e05f1bb27]
/usr/sbin/mysqld(+0x9102fc)[0x557e05ed12fc]
/usr/sbin/mysqld(+0x91766b)[0x557e05ed866b]
/usr/sbin/mysqld(+0x9189b2)[0x557e05ed99b2]
nptl/pthread_create.c:463(start_thread)[0x7f88665b66db]
x86_64/clone.S:97(clone)[0x7f886593461f]
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.
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Using Linux native AIO
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15743181397
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-04-07  2:30:58 140183385869440 [Note] InnoDB: Starting final batch to recover 15 pages from redo log
2025-04-07  2:30:59 140183385869440 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  2:30:59 140183385869440 [Note] InnoDB: Waiting for purge to start
2025-04-07  2:30:59 140183385869440 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15743185707
2025-04-07  2:31:16 140183385869440 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  2:31:16 140182703568640 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  2:31:16 140183385869440 [Note] Recovering after a crash using tc.log
2025-04-07  2:31:16 140183385869440 [Note] Starting crash recovery...
2025-04-07  2:31:16 140183385869440 [Note] Crash recovery finished.
2025-04-07  2:31:16 140183385869440 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  2:31:16 140183385869440 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  3:25:13 140182732928768 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 03:25:13 7f7ed5fff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  3:25:13 140182732928768 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  3:25:13 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=24
max_threads=1002
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55c4ffa506ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x55c4ff616cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f7efbd96980]
linux/raise.c:51(__GI_raise)[0x7f7efb026e87]
stdlib/abort.c:81(__GI_abort)[0x7f7efb0287f1]
/usr/sbin/mysqld(+0x836621)[0x55c4ff8b5621]
/usr/sbin/mysqld(+0x8378dd)[0x55c4ff8b68dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55c4ff9d99c3]
/usr/sbin/mysqld(+0x95ab27)[0x55c4ff9d9b27]
/usr/sbin/mysqld(+0x9102fc)[0x55c4ff98f2fc]
/usr/sbin/mysqld(+0x91766b)[0x55c4ff99666b]
/usr/sbin/mysqld(+0x9189b2)[0x55c4ff9979b2]
nptl/pthread_create.c:463(start_thread)[0x7f7efbd8b6db]
x86_64/clone.S:97(clone)[0x7f7efb10961f]
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.
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Using Linux native AIO
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15745739144
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-04-07  3:25:19 139621264587904 [Note] InnoDB: Recovered page 2812:54653 from the doublewrite buffer.
2025-04-07  3:25:20 139621264587904 [Note] InnoDB: Starting final batch to recover 4748 pages from redo log
2025-04-07  3:25:20 139621264587904 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  3:25:20 139621264587904 [Note] InnoDB: Waiting for purge to start
2025-04-07  3:25:21 139621264587904 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15746287705
2025-04-07  3:25:36 139620566169344 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  3:25:36 139621264587904 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  3:25:36 139621264587904 [Note] Recovering after a crash using tc.log
2025-04-07  3:25:36 139621264587904 [Note] Starting crash recovery...
2025-04-07  3:25:36 139621264587904 [Note] Crash recovery finished.
2025-04-07  3:25:36 139621264587904 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  3:25:36 139621264587904 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  8:30:45 139620603918080 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 08:30:45 7efbf47ff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  8:30:45 139620603918080 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  8:30:45 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=50
max_threads=1002
thread_count=50
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55659ba0b6ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x55659b5d1cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7efc1acf5980]
linux/raise.c:51(__GI_raise)[0x7efc19f85e87]
stdlib/abort.c:81(__GI_abort)[0x7efc19f877f1]
/usr/sbin/mysqld(+0x836621)[0x55659b870621]
/usr/sbin/mysqld(+0x8378dd)[0x55659b8718dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55659b9949c3]
/usr/sbin/mysqld(+0x95ab27)[0x55659b994b27]
/usr/sbin/mysqld(+0x9102fc)[0x55659b94a2fc]
/usr/sbin/mysqld(+0x91766b)[0x55659b95166b]
/usr/sbin/mysqld(+0x9189b2)[0x55659b9529b2]
nptl/pthread_create.c:463(start_thread)[0x7efc1acea6db]
x86_64/clone.S:97(clone)[0x7efc1a06861f]
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.
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Using Linux native AIO
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15746373608
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 102702848
2025-04-07  8:30:51 139869240376448 [Note] InnoDB: Starting final batch to recover 9 pages from redo log
2025-04-07  8:30:52 139869240376448 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  8:30:52 139868671829760 [Note] InnoDB: Starting in background the rollback of recovered transactions
2025-04-07  8:30:52 139869240376448 [Note] InnoDB: Waiting for purge to start
2025-04-07  8:30:52 139868671829760 [Note] InnoDB: Rollback of trx with id 102702501 completed
2025-04-07  8:30:52 139869240376448 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15746374562
2025-04-07  8:30:52 139868671829760 [Note] InnoDB: Rollback of trx with id 102702499 completed
2025-04-07  8:30:52 139868671829760 [Note] InnoDB: Rollback of non-prepared transactions completed
2025-04-07  8:31:41 139868671829760 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  8:31:41 139869240376448 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  8:31:41 139869240376448 [Note] Recovering after a crash using tc.log
2025-04-07  8:31:41 139869240376448 [Note] Starting crash recovery...
2025-04-07  8:31:41 139869240376448 [Note] Crash recovery finished.
2025-04-07  8:31:41 139869240376448 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  8:31:41 139869240376448 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  8:44:29 139868571170560 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 08:44:29 7f35b07ff700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  8:44:29 139868571170560 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  8:44:29 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=33
max_threads=1002
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5586544036ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x558653fc9cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f35d7519980]
linux/raise.c:51(__GI_raise)[0x7f35d67a9e87]
stdlib/abort.c:81(__GI_abort)[0x7f35d67ab7f1]
/usr/sbin/mysqld(+0x836621)[0x558654268621]
/usr/sbin/mysqld(+0x8378dd)[0x5586542698dd]
/usr/sbin/mysqld(+0x95a9c3)[0x55865438c9c3]
/usr/sbin/mysqld(+0x95ab27)[0x55865438cb27]
/usr/sbin/mysqld(+0x9102fc)[0x5586543422fc]
/usr/sbin/mysqld(+0x91766b)[0x55865434966b]
/usr/sbin/mysqld(+0x9189b2)[0x55865434a9b2]
nptl/pthread_create.c:463(start_thread)[0x7f35d750e6db]
x86_64/clone.S:97(clone)[0x7f35d688c61f]
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.
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Using Linux native AIO
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15746427769
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 102704384
2025-04-07  8:44:35 139740812520576 [Note] InnoDB: Starting final batch to recover 26 pages from redo log
2025-04-07  8:44:36 139740812520576 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  8:44:36 139740246435584 [Note] InnoDB: Starting in background the rollback of recovered transactions
2025-04-07  8:44:36 139740812520576 [Note] InnoDB: Waiting for purge to start
2025-04-07  8:44:36 139740246435584 [Note] InnoDB: Rollback of trx with id 102703922 completed
2025-04-07  8:44:36 139740246435584 [Note] InnoDB: Rollback of non-prepared transactions completed
2025-04-07  8:44:36 139740812520576 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15746436553
2025-04-07  8:44:45 139740133193472 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  8:44:45 139740812520576 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  8:44:45 139740812520576 [Note] Recovering after a crash using tc.log
2025-04-07  8:44:45 139740812520576 [Note] Starting crash recovery...
2025-04-07  8:44:45 139740812520576 [Note] Crash recovery finished.
2025-04-07  8:44:45 139740812520576 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  8:44:45 139740812520576 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  9:27:14 139740246435584 [ERROR] InnoDB: The OS said file flush did not succeed
2025-04-07 09:27:14 7f17cfbfe700  InnoDB: Operating system error number 1 in a file operation.
InnoDB: Error number 1 means 'Operation not permitted'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
 InnoDB: Operation flush to file /build/mariadb-10.1-CYSeUP/mariadb-10.1-10.1.48/storage/xtradb/os/os0file.cc and at line 2950
2025-04-07  9:27:14 139740246435584 [ERROR] InnoDB: File (unknown): 'flush' returned OS error 201. Cannot continue operation
250407  9:27:14 [ERROR] mysqld got signal 6 ;
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.1.48-MariaDB-0ubuntu0.18.04.1
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=40
max_threads=1002
thread_count=8
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2217522 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5621e71e06ae]
/usr/sbin/mysqld(handle_fatal_signal+0x53b)[0x5621e6da6cfb]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12980)[0x7f17f06c0980]
linux/raise.c:51(__GI_raise)[0x7f17ef950e87]
stdlib/abort.c:81(__GI_abort)[0x7f17ef9527f1]
/usr/sbin/mysqld(+0x836621)[0x5621e7045621]
/usr/sbin/mysqld(+0x8378dd)[0x5621e70468dd]
/usr/sbin/mysqld(+0x95a9c3)[0x5621e71699c3]
/usr/sbin/mysqld(+0x95ab27)[0x5621e7169b27]
/usr/sbin/mysqld(+0x9102fc)[0x5621e711f2fc]
/usr/sbin/mysqld(+0x91766b)[0x5621e712666b]
/usr/sbin/mysqld(+0x9189b2)[0x5621e71279b2]
nptl/pthread_create.c:463(start_thread)[0x7f17f06b56db]
x86_64/clone.S:97(clone)[0x7f17efa3361f]
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.
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: The InnoDB memory heap is disabled
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Using Linux native AIO
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Using SSE crc32 instructions
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Completed initialization of buffer pool
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Highest supported file format is Barracuda.
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Starting crash recovery from checkpoint LSN=15746619876
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
2025-04-07  9:27:20 140134955756672 [Note] InnoDB: Starting final batch to recover 16 pages from redo log
2025-04-07  9:27:21 140134955756672 [Note] InnoDB: 128 rollback segment(s) are active.
2025-04-07  9:27:21 140134955756672 [Note] InnoDB: Waiting for purge to start
2025-04-07  9:27:21 140134955756672 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.49-89.0 started; log sequence number 15746626015
2025-04-07  9:27:22 140134955756672 [Note] Plugin 'FEEDBACK' is disabled.
2025-04-07  9:27:22 140134271940352 [Note] InnoDB: Dumping buffer pool(s) not yet started
2025-04-07  9:27:22 140134955756672 [Note] Recovering after a crash using tc.log
2025-04-07  9:27:22 140134955756672 [Note] Starting crash recovery...
2025-04-07  9:27:22 140134955756672 [Note] Crash recovery finished.
2025-04-07  9:27:22 140134955756672 [Note] Server socket created on IP: '0.0.0.0'.
2025-04-07  9:27:22 140134955756672 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.1.48-MariaDB-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 18.04
2025-04-07  9:27:30 140134954755840 [Warning] Hostname 'cloudone-crm' does not resolve to '103.115.24.19'.
2025-04-07  9:27:30 140134954755840 [Note] Hostname 'cloudone-crm' has the following IP addresses:
2025-04-07  9:27:30 140134954755840 [Note]  - 127.0.1.1
2025-04-07  9:27:30 140134955165440 [Warning] Hostname 'cloudone-crm' does not resolve to '103.115.24.19'.
2025-04-07  9:27:30 140134955165440 [Note] Hostname 'cloudone-crm' has the following IP addresses:
2025-04-07  9:27:30 140134955165440 [Note]  - 127.0.1.1
2025-04-07  9:27:30 140134954346240 [Warning] Hostname 'cloudone-crm' does not resolve to '103.115.24.19'.
2025-04-07  9:27:30 140134954346240 [Note] Hostname 'cloudone-crm' has the following IP addresses:
2025-04-07  9:27:30 140134954346240 [Note]  - 127.0.1.1
2025-04-07  9:27:30 140134954960640 [Warning] Hostname 'cloudone-crm' does not resolve to '103.115.24.19'.
2025-04-07  9:27:30 140134954960640 [Note] Hostname 'cloudone-crm' has the following IP addresses:
2025-04-07  9:27:30 140134954960640 [Note]  - 127.0.1.1
2025-04-07  9:27:30 140134954551040 [Warning] Hostname 'cloudone-crm' does not resolve to '103.115.24.19'.
2025-04-07  9:27:30 140134954551040 [Note] Hostname 'cloudone-crm' has the following IP addresses:
2025-04-07  9:27:30 140134954551040 [Note]  - 127.0.1.1
2025-04-07  9:29:01 140134906283776 [Warning] IP address '103.72.169.219' could not be resolved: Name or service not known
2025-04-07  9:29:01 140134889756416 [Warning] IP address '103.72.169.219' could not be resolved: Name or service not known
2025-04-07 10:33:00 140134860814080 [Warning] IP address '182.92.202.149' could not be resolved: Name or service not known
2025-04-07 10:34:33 140134860814080 [Warning] IP address '103.108.229.76' could not be resolved: Name or service not known
2025-04-07 10:59:28 140134889551616 [Warning] IP address '80.66.88.99' could not be resolved: Name or service not known