app-office/akonadi-server mysql backend nonfunctional after upgrade to dev-db/mysql-5.5.39 Yes emerge @preserved-rebuild ran and worked fine. Here's the mysql.err log: 140822 14:10:29 InnoDB: The InnoDB memory heap is disabled 140822 14:10:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins 140822 14:10:29 InnoDB: Compressed tables use zlib 1.2.8 140822 14:10:29 InnoDB: Using Linux native AIO 140822 14:10:29 InnoDB: Initializing buffer pool, size = 80.0M 140822 14:10:29 InnoDB: Completed initialization of buffer pool InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 140822 14:10:29 InnoDB: Retrying to lock the first data file InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. [...] InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. InnoDB: Unable to lock ./ibdata1, error: 11 InnoDB: Check that you do not already have another mysqld process InnoDB: using the same InnoDB data or log files. 140822 14:12:09 InnoDB: Unable to open the first data file InnoDB: Error in opening ./ibdata1 140822 14:12:09 InnoDB: Operating system error number 11 in a file operation. InnoDB: Error number 11 means 'Resource temporarily unavailable'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html 140822 14:12:09 InnoDB: Could not open or create data files. 140822 14:12:09 InnoDB: If you tried to add new data files, and it failed here, 140822 14:12:09 InnoDB: you should now edit innodb_data_file_path in my.cnf back 140822 14:12:09 InnoDB: to what it was, and remove the new ibdata files InnoDB created 140822 14:12:09 InnoDB: in this failed attempt. InnoDB only wrote those files full of 140822 14:12:09 InnoDB: zeros, but did not yet use them in any way. But be careful: do not 140822 14:12:09 InnoDB: remove old data files which contain your precious data! 140822 14:12:09 [ERROR] Plugin 'InnoDB' init function returned error. 140822 14:12:09 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140822 14:12:09 [ERROR] Unknown/unsupported storage engine: innodb 140822 14:12:09 [ERROR] Aborting 140822 14:12:09 [Note] /usr/sbin/mysqld: Shutdown complete I tried running /usr/sbin/mysqld --defaults-file=/home/huettel/.local/share/akonadi/mysql.conf --datadir=/home/huettel/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-huettel.dhrlVb/mysql.socket & mysql_upgrade --socket=/tmp/akonadi-huettel.dhrlVb/mysql.socket which claims that all is OK with the database. It does not help though. More debugging to follow...
OK here's the secret for Gentoo: You MUST run revdep-rebuild. emerge @preserved-rebuild is NOT enough... Keeping the bug open until I/someone else writes a blog post.
Today I had to fix a related (or the same?) issue with app-office/akonadi-server-1.13.0 and dev-db/mysql-5.5.39 which is related to the Binary Log of MySQL (http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html). "akonadictl start" threw may errors of type "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."... Akonadi tried to upgrade the database and therefore used transaction level with InnoDB which InnoDB is only able to execute if "row"-based binary logging is enabled. MySQL 5.5 defaults to "statement"-based. I added binlog_format=MIXED to /etc/mysql/my.cnf to allow both logging methods. Afterwards akonadi was able to process all updates and continued working normally. As I said, the issue may be related but not yours, because i don't have errors in my mysql.err
You already found a solution. The "'emerge @preserved-rebuild' is not enough" issue appears sometimes for me too. I started to use both "emerge @preserved-rebuild" and revdeb-rebuild again.
Maybe I should really read those news items instead of just clicking them away...
