FS#68681 - [mariadb] akonadi crashes on start with mariadb 10.5.8

Attached to Project: Arch Linux
Opened by Xaver (x-f) - Friday, 20 November 2020, 06:58 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 09 June 2022, 17:35 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Akonadi 20.11.80 crashed after few hours and every start trying to fix the corrupt DB results in instant crash of mariaDB 10.5.8. No recovery mode (1-3) works.

Start
```
akonadictl start
org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl: done.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection!
org.kde.pim.akonadiserver: executable: "/usr/bin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/user/.local/share/akonadi/mysql.conf", "--datadir=/home/user/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: "2020-11-20 4:31:10 0 [Note] /usr/bin/mysqld (mysqld 10.5.8-MariaDB) starting as process 36543 ...\n"
org.kde.pim.akonadiserver: exit code: 6
org.kde.pim.akonadiserver: process error: "Process crashed"
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

```

gdb start
```
gdb --args /usr/bin/mysqld --defaults-file=/home/user/.local/share/akonadi/mysql.conf --datadir=/home/user/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid

(gdb) run
Starting program: /usr/bin/mysqld --defaults-file=/home/user/.local/share/akonadi/mysql.conf --datadir=/home/user/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
2020-11-20 7:27:48 0 [Note] /usr/bin/mysqld (mysqld 10.5.8-MariaDB) starting as process 68482 ...
[New Thread 0x7ffff7fc9640 (LWP 68486)]
[New Thread 0x7ffff6b12640 (LWP 68487)]
[New Thread 0x7ffff5f10640 (LWP 68488)]
[New Thread 0x7ffff530f640 (LWP 68489)]

Thread 1 "mysqld" received signal SIGABRT, Aborted.
```

MariaDB log
```
0 [Warning] option 'innodb-purge-threads': unsigned value 0 adjusted to 1
0 [Note] InnoDB: Using Linux native AIO
0 [Note] InnoDB: Uses event mutexes
0 [Note] InnoDB: Compressed tables use zlib 1.2.11
0 [Note] InnoDB: Number of pools: 1
0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
0 [Note] InnoDB: Completed initialization of buffer pool
0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2372408844,2372408844
0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=0, page number=314] with future log sequence number 2384902644
.....
0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=39, page number=108] with future log sequence number 2384905821
0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 2380969335 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 2376489968 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
.....
0 [ERROR] InnoDB: Page [page id: space=0, page number=207] log sequence number 2384842345 is in the future! Current system log sequence number 2372492099.
0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
0x7f4bc5171800 InnoDB: Assertion failure in file /build/mariadb/src/mariadb-10.5.8/storage/innobase/include/fut0lst.h line 127
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
[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.5.8-MariaDB
key_buffer_size=16384
read_buffer_size=131072
max_used_connections=0
max_threads=258
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 567951 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)[0x558a7a903bff]
??:0(handle_fatal_signal)[0x558a7a3e9d90]
sigaction.c:0(__restore_rt)[0x7f4bc58bf0f0]
:0(__GI_raise)[0x7f4bc53da615]
:0(__GI_abort)[0x7f4bc53c3862]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0ca414]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0c9eff]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x558a7a0ca177]
```
This task depends upon

Closed by  Antonio Rojas (arojas)
Thursday, 09 June 2022, 17:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  Old issue, no longer relevant
Comment by CLOVIS (clovis) - Tuesday, 24 November 2020, 14:22 GMT
Same issue with Akonadi 20.08.3-2 and MariaDB 10.5.8-1
Comment by Xaver (x-f) - Tuesday, 24 November 2020, 14:28 GMT
Workaround for me:
Delete the DB and all messages are downloaded again. No new problems sofar.
You need to set some standard folders again. i Created a dump of structure and also of data except the broken table, but the broken one is the main table for messages.Tried to delete restore and it worked. Never got to using the DB dumps.
Comment by Christian Hesse (eworm) - Tuesday, 24 November 2020, 16:24 GMT
Looks like MDEV-24162:
https://jira.mariadb.org/browse/MDEV-24162

The data was probably corrupted by mariadb 10.5.7...
Comment by Bennett Piater (ClawOfLight) - Wednesday, 25 November 2020, 18:52 GMT
I have the same problem. Deleting the DB might not be an option for me since I have a local archive as well, and I'm not sure what would happen to that?
Comment by Michał Walenciak (Kicer) - Thursday, 03 December 2020, 16:13 GMT
Any workarounds apart from deleting db?
Comment by CLOVIS (clovis) - Saturday, 05 December 2020, 18:33 GMT
Hi, I'm assuming that if I only use Kontact to access cloud services, deleting the local database will at worse just force me to re-login? If so, how can I do that?
Comment by Antonio Rojas (arojas) - Saturday, 05 December 2020, 19:22 GMT
Deleting the local database will not cause any harm in any case, the db is only a cache and the actual data is stored elsewhere. You cam rm -r ~/.local/share/akonadi
Comment by CLOVIS (clovis) - Saturday, 05 December 2020, 20:51 GMT
Thanks a lot @arojas, that did fix it for me.
Comment by Piero (hifi25nl) - Thursday, 09 June 2022, 17:34 GMT
I have tried rm -r ~/.local/share/akonadi but in my case did not solve the problem

Loading...