Summary: | dev-db/mysql-5.6.21-r1 crashes on app-office/akonadi-server-1.13.0 start | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pavel Volkov <ao> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mysql-bugs, pacho |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Find mysql_install_db and add required option |
Description
Pavel Volkov
2014-11-21 07:20:49 UTC
Does mysql work when launched manually, and is there anything in the mysql logs? It looks like mysql is failing to start correctly. Right, mysqld catshes SIGSEGV. This is how I run it manually: /usr/sbin/mysqld --debug=d:t:o,/tmp/mysql.crash --debug-check --defaults-file=/home/rondo/.local/share/akonadi/mysql.conf --datadir=/home/rondo/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-rondo.EK5c6C/mysql.socket It also exists with status 1. And last lines from strace: getcwd("/home/rondo/.local/share/akonadi/db_data", 4096) = 41 lseek(2, 0, SEEK_END) = 77599148 pread(2, "\273+\321\35\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0004\224.\350\0\7\0\0\0\0\0\0"..., 16384, 81920) = 16384 mmap(NULL, 2117632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbfea834000 pread(2, "]\324\256R\0\0\n\251\0\0\0\0\0\0\0\0\0\0\0\0004\2240A\0\2\0\0\0\0\0\0"..., 1048576, 1048576) = 1048576 pread(2, "\255\202Jv\0\0\1`\0\0\0\0\0\0\0\0\0\0\0\0004\224\26\364\0\2\0\0\0\0\0\0"..., 1048576, 2097152) = 1048576 pread(2, "15:12:04 UTC - mysqld got signal"..., 16384, 0) = 16384 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x23b5001} --- write(2, "15:35:46 UTC - mysqld got signal"..., 38) = 38 write(2, "This could be because you hit a "..., 226) = 226 write(2, "We will try our best to scrape u"..., 177) = 177 write(2, "key_buffer_size=16777216\n", 25) = 25 write(2, "read_buffer_size=262144\n", 24) = 24 write(2, "max_used_connections=0\n", 23) = 23 write(2, "max_threads=151\n", 16) = 16 write(2, "thread_count=0\n", 15) = 15 write(2, "connection_count=0\n", 19) = 19 write(2, "It is possible that mysqld could"..., 140) = 140 write(2, "Hope that's ok; if not, decrease"..., 66) = 66 write(2, "Thread pointer: 0x0\n", 20) = 20 write(2, "Attempting backtrace. You can us"..., 159) = 159 futex(0x7fbfff0df1b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7fbffed4b1b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(2, "stack_bottom = 0 thread_stack 0x"..., 38) = 38 writev(-1, [{"/usr/sbin/mysqld", 16}, {"(", 1}, {"my_print_stacktrace", 19}, {"+0x", 3}, {"20", 2}, {")", 1}, {"[0x", 3}, {"83eab0", 6}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"(", 1}, {"handle_fatal_signal", 19}, {"+0x", 3}, {"34d", 3}, {")", 1}, {"[0x", 3}, {"62025d", 6}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/lib64/libpthread.so.0", 22}, {"(", 1}, {"+0x", 3}, {"fd30", 4}, {")", 1}, {"[0x", 3}, {"7fbfff6eed30", 12}, {"]\n", 2}], 8) = -1 EBADF (Bad file descriptor) writev(-1, [{"/lib64/libz.so.1", 16}, {"(", 1}, {"adler32", 7}, {"+0x", 3}, {"17c", 3}, {")", 1}, {"[0x", 3}, {"7fc0003716bc", 12}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"8a652e", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"937a73", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"977aa8", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"8f0c4a", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"851c44", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"(", 1}, {"_Z24ha_initialize_handlertonP13s"..., 44}, {"+0x", 3}, {"41", 2}, {")", 1}, {"[0x", 3}, {"57da81", 6}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"6976e0", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"(", 1}, {"_Z11plugin_initPiPPci", 21}, {"+0x", 3}, {"91c", 3}, {")", 1}, {"[0x", 3}, {"69b6ec", 6}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"(", 1}, {"_Z11mysqld_mainiPPc", 19}, {"+0x", 3}, {"83f", 3}, {")", 1}, {"[0x", 3}, {"57789f", 6}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/lib64/libc.so.6", 16}, {"(", 1}, {"__libc_start_main", 17}, {"+0x", 3}, {"f5", 2}, {")", 1}, {"[0x", 3}, {"7fbffed6daa5", 12}, {"]\n", 2}], 9) = -1 EBADF (Bad file descriptor) writev(-1, [{"/usr/sbin/mysqld", 16}, {"[0x", 3}, {"56d055", 6}, {"]\n", 2}], 4) = -1 EBADF (Bad file descriptor) write(2, "The manual page at http://dev.my"..., 145) = 145 exit_group(1) = ? +++ exited with 1 +++ (In reply to Pavel Volkov from comment #2) > Right, mysqld catshes SIGSEGV. > > This is how I run it manually: > /usr/sbin/mysqld --debug=d:t:o,/tmp/mysql.crash --debug-check > --defaults-file=/home/rondo/.local/share/akonadi/mysql.conf > --datadir=/home/rondo/.local/share/akonadi/db_data/ > --socket=/tmp/akonadi-rondo.EK5c6C/mysql.socket > Please always specify --defaults-file first. There are issues that will ignore settings if you do not. > It also exists with status 1. > > And last lines from strace: Can you please post from the mysqld.err (or whatever log-error is set in defaults-file) file instead? This is rather unreadable when most of the text is cut off. This is mysql.err: 2014-11-27 21:00:05 5586 [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000) 2014-11-27 21:00:05 5586 [Warning] Buffered warning: Changed limits: max_connections: 214 (requested 256) 2014-11-27 21:00:05 7f06ecce4740 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator. 2014-11-27 21:00:05 5586 [Note] InnoDB: Using atomics to ref count buffer pool pages 2014-11-27 21:00:05 5586 [Note] InnoDB: The InnoDB memory heap is disabled 2014-11-27 21:00:05 5586 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2014-11-27 21:00:05 5586 [Note] InnoDB: Memory barrier is not used 2014-11-27 21:00:05 5586 [Note] InnoDB: Compressed tables use zlib 1.2.8 2014-11-27 21:00:05 5586 [Note] InnoDB: Using Linux native AIO 2014-11-27 21:00:05 5586 [Note] InnoDB: Using CPU crc32 instructions 2014-11-27 21:00:05 5586 [Note] InnoDB: Initializing buffer pool, size = 80.0M 2014-11-27 21:00:05 5586 [Note] InnoDB: Completed initialization of buffer pool 2014-11-27 21:00:05 5586 [ERROR] InnoDB: Space id in fsp header 1416128883,but in the page header 824195850 18:00:05 UTC - 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. 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. key_buffer_size=16384 read_buffer_size=131072 max_used_connections=0 max_threads=214 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 85119 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 = 0 thread_stack 0x40000 /usr/sbin/mysqld(my_print_stacktrace+0x20)[0x83eab0] /usr/sbin/mysqld(handle_fatal_signal+0x34d)[0x62025d] /lib64/libpthread.so.0(+0xfd30)[0x7f06eba72d30] /lib64/libz.so.1(adler32+0x17c)[0x7f06ec6f56bc] /usr/sbin/mysqld[0x8a652e] /usr/sbin/mysqld[0x937a73] /usr/sbin/mysqld[0x977aa8] /usr/sbin/mysqld[0x8f0c4a] /usr/sbin/mysqld[0x851c44] /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x57da81] /usr/sbin/mysqld[0x6976e0] /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x91c)[0x69b6ec] /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x83f)[0x57789f] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f06eb0f1aa5] /usr/sbin/mysqld[0x56d055] The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. Does mysql start normally against a clean database? (ie. not passing the akonadi data dir arguments) I tried logging into KDE with a new user — mysqld starts normally there I guess your akonadi database is corrupted in such a way causing mysql to crash. I agree that it looks like corrupt data. If you want to compile mysql with debug symbols, there may be bug reports out there to search. (Example here https://wiki.gentoo.org/wiki//etc/portage/env ) If you wish to try to work around this: 1) Try using dev-db/mariadb instead. This will use xtradb as an innodb replacement and may have better success. 2) Try https://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html to enable you to dump the data (mysqldump), delete the old files, recreate new and import from the dump. I tried mariadb and recoveing InnoDB — it's still broken. I think I'll wait until Plasma/Frameworks/Applications 5 are packaged and then reconfigure the entire desktop environment... Same behavior here. Reopening. (In reply to Andreas K. Hüttel from comment #11) > http://forums.gentoo.org/viewtopic-t-967722-view-next.html > Same problem dev-db/mysql needs debug symbols for a decent backtrace in the error message. Without this, it is pure speculation to what is causing it. The OP is more likely to have corrupt data due to: > 2014-11-27 21:00:05 5586 [ERROR] InnoDB: Space id in fsp header 1416128883,but in the page header 824195850 The forum post output did not list it. I just ran into some crashing issues (independent of akonadi) and it was solved by mysql_upgrade. Without a backtrace or a way to duplicate, I suggest closing this as NEEDINFO. The only speculation I can think of without it is akonadi not creating the system tables which can be used for more than authentication. Again, without more info, this is only a guess. Created attachment 393480 [details, diff]
Find mysql_install_db and add required option
One issue I see that may be related is from akonadi-server startup:
`Found mysql_install_db: ""`
On first run, it executes an empty string and carries on its merry way without error.
The mysql system tables are critical for operations. They contain more than just logins and permissions these days and may cause a crash if something tries to read/write to them.
Attached is a patch to fix this horrible detection.
For those already affected, you should run `/usr/share/mysql/scripts/mysql_install_db --defaults-file=~/.local/share/akonadi/mysql.conf --force --datadir=~/.local/share/akonadi/db_data/ --basedir=/usr` while akonadi-server is stopped.
Please report if this helps.
Removing blocks as recommended by KDE team (In reply to Brian Evans from comment #15) > For those already affected, you should run > `/usr/share/mysql/scripts/mysql_install_db > --defaults-file=~/.local/share/akonadi/mysql.conf --force > --datadir=~/.local/share/akonadi/db_data/ --basedir=/usr` while > akonadi-server is stopped. > > Please report if this helps. Correction on the workaround command: `/usr/share/mysql/scripts/mysql_install_db --defaults-file=${HOME}/.local/share/akonadi/mysql.conf --datadir=${HOME}/.local/share/akonadi/db_data/ --basedir=/usr` Seems it does not like the ~ expansion. @kde: what's the status of patching this? It looks OK. I'm not actively using akonadi-server so I haven't been able to test. Thanks all. I have added the patch to a new revision as it doesn't break my systen. + + 26 Jun 2015; Johannes Huber <johu@gentoo.org> + +akonadi-server-1.13.0-r1.ebuild, + +files/akonadi-server-1.13.0-mysql56-crash.patch, + akonadi-server-1.13.0.ebuild: + Revision bump adds patch by Brian Evans <grknight@gentoo.org>, fixes a crash + with dev-db/mysql-5.6m bug #530012. + |