After having updated to 4.8.1 I added an IMAP resource for a dovecot2 mail server. After that process I was trying to load messages (read and unread) from that server. I assume I was hit by the bug of <https://bugs.kde.org/show_bug.cgi?id=295484> as the only unread message in the inbox lost its body. At some point Kmail2 crashed and I rebooted my computer. Kmail2 then listed my mail hierarchy, but didn't show the mail contents. I looked into .xsession-errors and observed many occurrences like found 1 item parts to expire in collection "INBOX" Error during updating record with id 11438 in table "PartTable" "Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. QMYSQL3: Unable to execute statement" failed to update item part 11438 Decided to recreate Akonadi's database, deleted "~/.local/share/akonadi" and started the command "akonadictl start". There still was a problem regarding the setting for locking database objects: Database "akonadi" opened using driver "QMYSQL" DbInitializer::run() checking table "SchemaVersionTable" "INSERT INTO SchemaVersionTable (version) VALUES (20)" "Unable to add initial data to table 'SchemaVersionTable'. Query error: 'Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. QMYSQL: Unable to execute query' Query was: INSERT INTO SchemaVersionTable (version) VALUES (20)" Unable to initialize database. "[ 0: akonadiserver(_Z11akBacktracev+0x35) [0x453ba5] 1: akonadiserver() [0x453e6c] 2: /lib64/libc.so.6(+0x34e10) [0x7f91cd1b2e10] 3: /lib64/libc.so.6(gsignal+0x35) [0x7f91cd1b2d95] 4: /lib64/libc.so.6(abort+0x17b) [0x7f91cd1b42ab] 5: /usr/lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7f91cec79c84] 6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0x92) [0x456142] 7: /usr/lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0xaf) [0x7f91ced1482f] 8: /usr/lib64/libQtCore.so.4(+0x11de02) [0x7f91ced1fe02] 9: /usr/lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x39) [0x7f91ced28c99] 10: akonadiserver() [0x45abd8] 11: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x35) [0x45bd45] 12: akonadiserver(main+0x1ea) [0x44c0da] 13: /lib64/libc.so.6(__libc_start_main+0xed) [0x7f91cd19f23d] 14: akonadiserver() [0x44c871] ] " ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error) After that I explicitly added "binlog_format=mixed" to "~/.config/akonadi/mysql-local.conf". Akonadi and Kmail2 now work as expected.
I'm observing similar problems fetching emails. I can't remember kmail crashing before this happened, but it won't download new mails anymore (using KDE packages from either KDE:Distro:Factory or KDE:Release:48 from today on openSUSE) Error during executing query "UPDATE PimItemTable SET atime = :0 WHERE ( ( PimItemTable.id = :1 ) )" : "Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. QMYSQL3: Unable to execute statement" Unable to update item access time Error during updating record with id 26631 in table "PartTable" "Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED. QMYSQL3: Unable to execute statement" continuing
What MySQL server version are you using?
Git commit 8f6eb20aaa854224a6d4070ee2459290ec431576 by Volker Krause. Committed on 14/04/2012 at 14:50. Pushed by vkrause into branch 'master'. Set the MySQL binlog format explicitly. The combination of the transaction isolation level we use and the default binlog format doesn't work. Newer MySQL versions (>= 5.5 apparently) automatically switch to a supported format, older ones just fail. We don't actually enable the binlog, nor do we need it, so I don't really know why it's on for some users in the first place. M +5 -0 server/src/storage/mysql-global.conf http://commits.kde.org/akonadi/8f6eb20aaa854224a6d4070ee2459290ec431576
(In reply to comment #3) > What MySQL server version are you using? MySQL tells me: ~> /usr/sbin/mysqld --version /usr/sbin/mysqld Ver 5.5.16 for Linux on x86_64 (Source distribution)
Reopening this bug because it appears that the change to the config file above does not work with older MySQL versions: $ /usr/sbin/mysqld --version /usr/sbin/mysqld Ver 5.1.61-log for pc-linux-gnu on i686 (Gentoo Linux mysql-5.1.61) $ cat /home/jjm/.local/share/akonadi/db_data/mysql.err 120415 21:18:14 [ERROR] You need to use --log-bin to make --binlog-format work. 120415 21:18:14 [ERROR] Aborting 120415 21:18:14 [Note] /usr/sbin/mysqld: Shutdown complete $ tail -7 /home/jjm/.local/share/akonadi/mysql.conf # we are not using the binlog, but some users seem to have it enabled nevertheless # in combination with our transaction isolation level and older mysql versions this can causes errors # due to incompatible log formats (see e.g. bug 295700). binlog_format=mixed [client] default-character-set=utf8 $ Removing the "binlog_format=mixed" line from mysql.conf allows MySQL and therefore Akonadi to start.
I'm experiencing the same problem described by Jonathan in comment #6 with MySQL 5.1.62.
My fix indeed was too aggressive for older MySQL versions and has just been reverted. If you are affected by the original problem, please post your ~/.local/share/akonadi/mysql.conf file, or at least check if that for some reason contains a "log_bin=..." line (it should not).
Apparently this is still an issue for people from time to time, and documented workarounds start to emerge, so I think we should either figure out what's going on or enforce from akonadi that log_bin is not in the config.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.