akonadi mysql 5.6 crash with signal 11

Bug #1437846 reported by René Fritz on 2015-03-29
92
This bug affects 19 people
Affects Status Importance Assigned to Milestone
akonadi (Ubuntu)
Undecided
Unassigned
mysql-5.6 (Ubuntu)
Undecided
Unassigned

Bug Description

Vivid changed mysql version recently to 5.6. Akonadi won't start anymore because mysql crash - log attached.

I wanted to install a mysql dbg package but couldn't find the right one.
I would like to provide more information but can't think of any valuable for now.

akonadi test log is all good

MySQL server is executable.
Details: MySQL server found: /usr/sbin/mysqld Ver 5.6.23-1~exp1~ubuntu4 for debian-linux-gnu on x86_64 ((Ubuntu))

René Fritz (ubuntu-colorcube) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in akonadi (Ubuntu):
status: New → Confirmed
Vasco Alves (vascofalves) wrote :

Confirm, this affects me too, can't use any Akonadi dependent applications ever since the mysql 5.6 upload.

Philip Muškovac (yofel) on 2015-04-03
affects: akonadi (Ubuntu) → mysql-5.6 (Ubuntu)
themroc (rauchweihe) wrote :

Same here with mysqld 5.6.24-0ubuntu1

Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I can't reproduce this. I tried installing akonadi-server and akonadi-mysql-backend but that doesn't seem to cause anything to start. I am not familiar with akonadi. Can someone please provide exact steps to reproduce this issue on a fresh Vivid cloud instance?

Changed in mysql-5.6 (Ubuntu):
status: Confirmed → Incomplete
René Fritz (ubuntu-colorcube) wrote :

I can't say why, but it works again for me.

akonadi-backend-mysql is version 1.13.0-2ubuntu4
mysql* is 5.6.24-0ubuntu1

I had a second error which was caused by a wrong configuration (may was set by a package?)
/usr/sbin/mysqld-akonadi has to be used as mysql executable.
Check with akonadi console Server>Configure Server

Ray-Ven (ray-ven) wrote :

I have to add, that akonadi works on a fresh created user. But I'd love to not have to recreate my whole akonadi settings (and, I don't know if that will work too).

Ray-Ven (ray-ven) wrote :

workaround: delete ~/.local/share/akonadi
But do this which caution: your database will be lost. In my case all my kontact-related settings and accounts stayed, but all my email is being downloaded from imap again.

Norvald H. Ryeng (nryeng) wrote :

In both error logs, I see this sequence (with varying timestamps and seq numbers, of course):

2015-03-29 15:03:37 2265 [Note] InnoDB: The log sequence numbers 10740390801 and 10740390801 in ibdata files do not match the log sequence number 11404279789 in the ib_logfiles!
2015-03-29 15:03:37 2265 [Note] InnoDB: Database was not shutdown normally!
2015-03-29 15:03:37 2265 [Note] InnoDB: Starting crash recovery.

I think that's the core of the problem. 5.5 was not shut down properly before upgrading, so it's left to 5.6 to try to recover. For some reason it can't, and it crashes.

Viktor Rasmussen (viktor-5) wrote :

So I have the same problem after an innocent "apt-get dist-upgrade" today.

Have we lost all our emails in KMail because of this, or can something be done to get it working again?

Viktor Rasmussen (viktor-5) wrote :

I removed the two files
~/.local/share/akonadi/db_data/ib_logfile0
and ~/.local/share/akonadi/db_data/ib_logfile1

Now Akonadi starts. And it seems no mails are lost

Robie Basak (racb) wrote :

Seems to me that it's akonadi that is failing to shut mysqld down properly when it is running 5.5 that is causing the issue - possibly with lack of database migration to 5.6?

There's a separate crash bug in mysqld that should be fixed (it shouldn't segfault no matter what really), but I'll add a task back for akonadi as it is the akonadi package that needs to keep affairs in ~/.local/share/akonadi/ in order.

Robie Basak (racb) wrote :

To fix the crash bug in mysql-5.6 we need a minimal failure case (steps to reproduce) really, so leaving that as Incomplete. The aknoadi management of ~/.local/share/akonadi might be able to make progress though if somebody who looks after akonadi packaging can look into that.

Philip Muškovac (yofel) wrote :

The Shutdown procedure is:

- run mysqladmin shutdown, wait 3 seconds (if mysqladmin exists, which on kubuntu isn't true by default as we only install mysql-client-core, not mysql-client)
- if server still runs, send SIGTERM to the server, wait another 3 seconds
- if server *still* runs, send SIGKILL

this is ofc. only true if the user properly logs out...

Regarding the database upgrade, mysql_upgrade is installed by default, so that *should* work, as long as mysql takes care of that (akonadi doesn't)

On Tue, Apr 21, 2015 at 10:45:03AM -0000, Philip Muškovac wrote:
> Regarding the database upgrade, mysql_upgrade is installed by default,
> so that *should* work, as long as mysql takes care of that (akonadi
> doesn't)

AFAIK, mysql packaging will only touch /var/lib/mysql. If you have a
custom started daemon with a database elsewhere (which is what akonadi
appears to do), mysql packaging won't touch it. akonadi packaging will
need to take care of this.

Vasco Alves (vascofalves) wrote :

Can confirm the above fix by Viktor works! Thanks a bunch!

Kai Michael Hamich (kmh) wrote :

For me this does not solve the problem ...

Attached is my Akonadi-Log

Jonathan Riddell (jr) on 2015-04-22
Changed in akonadi (Ubuntu):
milestone: none → ubuntu-15.04
tags: added: kubuntu
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in akonadi (Ubuntu):
status: New → Confirmed

Comment #11 solved the problem for me, too. I ran into the bug performing the following steps:

1. I upgraded Kubuntu from 14.10 to 15.04 using `sudo do-release-upgrade`.
2. I rebooted using `sudo reboot now` instead of using the K menu due to a bug that prevented me from rebooting via menu. According to the attached excerpt of mysql.err, mysqld was shutdown properly.
3. After rebooting, the crash appeared.

Johnny (johnny-geling) wrote :

I solved this issue.

This is what I did.
- I deleted from folder .local/share/akonadi/
  - socket-(computername)
  - mysql.conf
- Start Akonadi server.

=> problem solved. Akonadi server started normal

Maybe this helps solving the problem.

Angel (angel72) wrote :
Download full text (18.3 KiB)

1. Initially mysqld-akonadi could not start because of an error described as:

           "TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option"

2. In order to prevent that error, I modified the MySQL server configuration, adding the next lines to the file /etc/akonadi/mysql-global.conf:

           explicit_defaults_for_timestamp=1

3. After that, MySQL server starts correctly , but the problem is still there: the Akonadi server does not start up and the control process is not registered at D-Bus (errors in tests 10 and 11)

4. In fact, the akonadi server could not startup because of the next error:

        Sql error: Table 'akonadi.schemaversiontable' doesn't exist QMYSQL: Unable to execute query
        Query: ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
        Unable to initialize database.

5. Solutions #11 and #20 do not solve the problem for me.

6. Below you will find the Akonadi Server Self-Test Report:

Akonadi Server Self-Test Report
===============================

Test 1: SUCCESS
--------

Database driver found.
Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system.

File content of '/home/angel/.config/akonadi/akonadiserverrc':
[%General]
Driver=QMYSQL

[QMYSQL]
Name=akonadi
Host=
Options="UNIX_SOCKET=/tmp/akonadi-angel.D28OlA/mysql.socket"
ServerPath=/usr/sbin/mysqld-akonadi
StartServer=true

[Debug]
Tracer=null

Test 2: SUCCESS
--------

Akonadi is not running as root
Details: Akonadi is not running as a root/administrator user, which is the recommended setup for a secure system.

Test 3: SUCCESS
--------

MySQL server found.
Details: You have currently configured Akonadi to use the MySQL server '/usr/sbin/mysqld-akonadi'.
Make sure you have the MySQL server installed, set the correct path and ensure you have the necessary read and execution rights on the server executable. The server executable is typically called 'mysqld'; its location varies depending on the distribution.

Test 4: SUCCESS
--------

MySQL server is executable.
Details: MySQL server found: /usr/sbin/mysqld Ver 5.6.24-0ubuntu2 for debian-linux-gnu on i686 ((Ubuntu))

Test 5: SUCCESS
--------

No current MySQL error log found.
Details: The MySQL server did not report any errors during this startup. The log can be found in '/home/angel/.local/share/akonadi/db_data/mysql.err'.

Test 6: SUCCESS
--------

MySQL server default configuration found.
Details: The default configuration for the MySQL server was found and is readable at <a href='/etc/akonadi/mysql-global.conf'>/etc/akonadi/mysql-global.conf</a>.

File content of '/etc/akonadi/mysql-global.conf':
#
# Global Akonadi MySQL server settings,
# These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf
#
# Based on advice by Kris Köhntopp <email address hidden>
#
[mysqld]

# strict query parsing/interpretation
# TODO: make Akonadi work with those settings enabled
# sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_ze...

I can confirm the fix worked for me was to change from mysql to maria DB as per

https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/1445383/comments/3

Everything started up correctly after it installed mariadb. Thanks folks.

Angel (angel72) wrote :

Finally the workaround proposed by #10 (delete ~/.local/share/akonadi) solved the problem for me. Everything is OK now with akonadi, Kontact and MySql.

Mikael Bergqvist (mikaelb) wrote :

Did as Viktor Rasmussen suggested above. and removed the two files:
~/.local/share/akonadi/db_data/ib_logfile0
and ~/.local/share/akonadi/db_data/ib_logfile1

Mikael Bergqvist (mikaelb) wrote :

Last part of my comment disappeared:

Removing the two files made it possible to restart akonadi and get Kmail (and other) working again.

O. Sinclair (o-sinclair) wrote :

# 22 works perfectly for me on 14.10 and makes all KDEPIM snappier:

I have another solution:
- 1st i run update:
sudo aptitude update
when it is done then:
sudo aptitude purge mysql-server-core-5.6 mysql-client-core-5.6
aptitute will tell it has many dependencies, many packages will be removed ... so it asks if i accept that solution - choose no (n)
then it will propose installing:

1) mariadb-client-core-10.0 [10.0.17-0ubuntu1 (vivid)]
2) mariadb-common [10.0.17-0ubuntu1 (vivid)]
3) mariadb-server-core-10.0 [10.0.17-0ubuntu1 (vivid)]

- if you accept this - mysql will be removed, mariadb (fork of mysql) will be installed, and akonadi will start without any issues.

Piotr Kęplicz (keplicz) wrote :

I've had similar problems. It seems to me that the default Akonadi options for MySQL include a table_cache parameter, but it's been deprecated since 5.1 and in 5.6 prevents a start of the database. Removing this options did the trick for me.

In MariaDB documentation there's a remark that "all versions of MariaDB are based on MySQL 5.1 and greater, thus the table_cache option is deprecated in favor of table_open_cache."

Changed in akonadi (Ubuntu):
milestone: ubuntu-15.04 → none
Bas Roufs (basroufs) wrote :

I have had the same problem in Kubuntu 14.04. I have purged mysql 5.5. in my case; when doing so, mariadb 5.5. have been installed automatically. Now, everything from Kontact seems to work again, except Akregator Feeds.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers