Akonadi fails to start. When starting with "akonadictl start": org.kde.pim.akonadiserver: Database error: Cannot open database. org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" QSqlQuery::exec: database not open org.kde.pim.akonadiserver: Database error: Cannot open database. org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" QSqlQuery::exec: database not open org.kde.pim.akonadiserver: Unable to open database "Plugin pvio_socket could not be loaded: not initialized QMYSQL: Unable to connect" org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...
Please disclose your version of kde-apps/akonadi.
I can confirm this, same situation occurs on my machine too. My akonadi version: kde-apps/akonadi-17.04.3:5::gentoo builded with flags: USE="mysql tools -debug -designer -postgres -sqlite {-test} -xml"
Sorry, mail is not working, so my response may take longer ;) kde-apps/akonadi-17.04.3 (mysql tools xml -debug -designer -postgres -sqlite -test) dev-qt/qtsql-5.7.1 (mysql sqlite -debug -freetds -oci8 -odbc -postgres -test) dev-db/mariadb-10.2.7-r1 (backup cracklib embedded extraengine pam perl server xml -bindist -debug -galera -innodb-lz4 -innodb-lzo -innodb-snappy -jdbc -jemalloc -kerberos -latin1 -libressl -mroonga -odbc -oqgraph -profiling -rocksdb -selinux -sphinx -sst-rsync -sst-xtrabackup -static -static-libs -systemd -systemtap -tcmalloc -test -tokudb -yassl ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" ELIBC="-FreeBSD")
Btw, I rated it major because akonadi (=mail, ...) is not working anymore and a downgrade of mariadb does work as well. ("Unknown/unsupported storage engine: innodb")
downgrade does _not_ work
same here? (In reply to Markus from comment #5) > downgrade does _not_ work Downgrading work's: akonadiserver is running fine with <mariadb-10.2
(In reply to Andreas Sturmlechner from comment #1) > Please disclose your version of kde-apps/akonadi. 17.04.3
(In reply to Richard Hering from comment #6) > same here? > > (In reply to Markus from comment #5) > > downgrade does _not_ work > > Downgrading work's: akonadiserver is running fine with <mariadb-10.2 akonadi worked with mariadb 10.1.25 before, yes. Then I updated to 10.2.7 and the sql server started but akonadi failed. After this I was not able to use mariadb 10.1.25 again, it failed with "Unknown/unsupported storage engine: innodb".
If someone could post a full server startup log, that would be most helpful. Though I don't know the location off the top of my head.
$ akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) akonadi.collectionattributetable OK akonadi.collectionmimetyperelation OK akonadi.collectionpimitemrelation OK akonadi.collectiontable OK akonadi.flagtable OK akonadi.mimetypetable OK akonadi.parttable OK akonadi.parttypetable OK akonadi.pimitemflagrelation OK akonadi.pimitemtable OK akonadi.pimitemtagrelation OK akonadi.relationtable OK akonadi.relationtypetable OK akonadi.resourcetable OK akonadi.schemaversiontable OK akonadi.tagattributetable OK akonadi.tagremoteidresourcerelationtable OK akonadi.tagtable OK akonadi.tagtypetable OK org.kde.pim.akonadiserver: Database error: Cannot open database. org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" QSqlQuery::exec: database not open org.kde.pim.akonadiserver: Database error: Cannot open database. org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" QSqlQuery::exec: database not open org.kde.pim.akonadiserver: Unable to open database "Plugin pvio_socket could not be loaded: not initialized QMYSQL: Unable to connect" org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...
~/.local/share/akonadi/db_data/mysql.err: 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Uses event mutexes 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Compressed tables use zlib 1.2.11 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Using Linux native AIO 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Number of pools: 1 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Using SSE2 crc32 instructions 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Completed initialization of buffer pool 2017-07-29 16:46:40 139836722210560 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Highest supported file format is Barracuda. 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: 128 out of 128 rollback segments are active. 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Creating shared tablespace for temporary tables 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Waiting for purge to start 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: 5.7.18 started; log sequence number 325924495672 2017-07-29 16:46:40 139836082091776 [Note] InnoDB: Loading buffer pool(s) from /home/markus/.local/share/akonadi/db_data/ib_buffer_pool 2017-07-29 16:46:40 139836082091776 [Note] InnoDB: Buffer pool(s) load completed at 170729 16:46:40 2017-07-29 16:46:40 139837057918784 [Note] CONNECT: Version 1.06.0001 April 17, 2017 2017-07-29 16:46:40 139837057918784 [Note] Plugin 'FEEDBACK' is disabled. 2017-07-29 16:46:40 139837057918784 [Note] Reading of all Master_info entries succeded 2017-07-29 16:46:40 139837057918784 [Note] Added new Master_info '' to hash table 2017-07-29 16:46:40 139837057918784 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.2.7-MariaDB' socket: '/tmp/akonadi-markus.HyXupD/mysql.socket' port: 0 Source distribution 2017-07-29 16:46:41 139836810446592 [Note] /usr/sbin/mysqld ([markus] @ localhost []): Normal shutdown 2017-07-29 16:46:41 139836602177280 [Note] InnoDB: FTS optimize thread exiting. 2017-07-29 16:46:41 139836810446592 [Note] InnoDB: Starting shutdown... 2017-07-29 16:46:41 139836082091776 [Note] InnoDB: Dumping buffer pool(s) to /home/markus/.local/share/akonadi/db_data/ib_buffer_pool 2017-07-29 16:46:41 139836082091776 [Note] InnoDB: Buffer pool(s) dump completed at 170729 16:46:41 2017-07-29 16:46:42 139836810446592 [Note] InnoDB: Shutdown completed; log sequence number 325924495700 2017-07-29 16:46:42 139836810446592 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2017-07-29 16:46:42 139836810446592 [Note] /usr/sbin/mysqld: Shutdown complete
(In reply to Markus from comment #11) > ~/.local/share/akonadi/db_data/mysql.err: > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Mutexes and rw_locks use > GCC atomic builtins > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Uses event mutexes > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Compressed tables use > zlib 1.2.11 > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Using Linux native AIO > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Number of pools: 1 > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Using SSE2 crc32 > instructions > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Initializing buffer pool, > total size = 128M, instances = 1, chunk size = 128M > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Completed initialization > of buffer pool > 2017-07-29 16:46:40 139836722210560 [Note] InnoDB: If the mysqld execution > user is authorized, page cleaner thread priority can be changed. See the man > page of setpriority(). > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Highest supported file > format is Barracuda. > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: 128 out of 128 rollback > segments are active. > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Creating shared > tablespace for temporary tables > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Setting file './ibtmp1' > size to 12 MB. Physically writing the file full; Please wait ... > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: File './ibtmp1' size is > now 12 MB. > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: Waiting for purge to start > 2017-07-29 16:46:40 139837057918784 [Note] InnoDB: 5.7.18 started; log > sequence number 325924495672 > 2017-07-29 16:46:40 139836082091776 [Note] InnoDB: Loading buffer pool(s) > from /home/markus/.local/share/akonadi/db_data/ib_buffer_pool > 2017-07-29 16:46:40 139836082091776 [Note] InnoDB: Buffer pool(s) load > completed at 170729 16:46:40 > 2017-07-29 16:46:40 139837057918784 [Note] CONNECT: Version 1.06.0001 April > 17, 2017 > 2017-07-29 16:46:40 139837057918784 [Note] Plugin 'FEEDBACK' is disabled. > 2017-07-29 16:46:40 139837057918784 [Note] Reading of all Master_info > entries succeded > 2017-07-29 16:46:40 139837057918784 [Note] Added new Master_info '' to hash > table > 2017-07-29 16:46:40 139837057918784 [Note] /usr/sbin/mysqld: ready for > connections. > Version: '10.2.7-MariaDB' socket: '/tmp/akonadi-markus.HyXupD/mysql.socket' > port: 0 Source distribution > 2017-07-29 16:46:41 139836810446592 [Note] /usr/sbin/mysqld ([markus] @ > localhost []): Normal shutdown > > 2017-07-29 16:46:41 139836602177280 [Note] InnoDB: FTS optimize thread > exiting. > 2017-07-29 16:46:41 139836810446592 [Note] InnoDB: Starting shutdown... > 2017-07-29 16:46:41 139836082091776 [Note] InnoDB: Dumping buffer pool(s) to > /home/markus/.local/share/akonadi/db_data/ib_buffer_pool > 2017-07-29 16:46:41 139836082091776 [Note] InnoDB: Buffer pool(s) dump > completed at 170729 16:46:41 > 2017-07-29 16:46:42 139836810446592 [Note] InnoDB: Shutdown completed; log > sequence number 325924495700 > 2017-07-29 16:46:42 139836810446592 [Note] InnoDB: Removed temporary > tablespace data file: "ibtmp1" > 2017-07-29 16:46:42 139836810446592 [Note] /usr/sbin/mysqld: Shutdown > complete This indicates MariaDB is starting and shutting down normally. So this is something on akonadi's end. One major change that happened in MariaDB 10.2 is the SQL_MODE default changed from "NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER" in 10.1 to "NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO". This is detailed at https://mariadb.com/kb/en/mariadb/sql-mode/
Same behaviour here: kde-apps/akonadi-17.04.3:5 dev-db/mariadb-10.2.7-r1 snippet of akonadi self test: Test 10: ERROR -------- No resource agents found. Details: No resource agents have been found, Akonadi is not usable without at least one. This usually means that no resource agents are installed or that there is a setup problem. The following paths have been searched: '/usr/share/akonadi/agents'. The XDG_DATA_DIRS envi ronment variable is set to '/usr/local/share:/usr/share:/usr/share/mesa/xdg'; make sure this includes all paths where Akonadi agents are installed. Directory listing of '/usr/share/akonadi/agents': akonadiindexingagent.desktop akonotesresource.desktop archivemailagent.desktop birthdaysresource.desktop contactsresource.desktop davgroupwareresource.desktop followupreminder.desktop googlecalendarresource.desktop googlecontactsresource.desktop icaldirresource.desktop icalresource.desktop imapresource.desktop invitationsagent.desktop kalarmdirresource.desktop kalarmresource.desktop knutresource.desktop maildirresource.desktop maildispatcheragent.desktop mailfilteragent.desktop mboxresource.desktop migrationagent.desktop mixedmaildirresource.desktop newmailnotifieragent.desktop notesagent.desktop notesresource.desktop openxchangeresource.desktop pop3resource.desktop sendlateragent.desktop tomboynotesresource.desktop vcarddirresource.desktop vcardresource.desktop Environment variable XDG_DATA_DIRS is set to '/usr/local/share:/usr/share:/usr/share/mesa/xdg' Test 11: SUCCESS -------- No current Akonadi server error log found. Details: The Akonadi server did not report any errors during its current startup. Test 12: ERROR -------- Previous Akonadi server error log found. Details: The Akonadi server reported errors during its previous startup. The log can be found in <a href="/home/cova/.local/share/akonadi/akonadiserver.error.old">/home/cova/.local/share/akonadi/akonadiserver.error.old</a>. File content of '/home/cova/.local/share/akonadi/akonadiserver.error.old': QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.Database error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Plugin pvio_socket could not be loaded: not initialized"QSqlQuery::exec: database not openDatabase error: Cannot open database. Last driver error: "QMYSQL: Unable to connect" Last database error: "Plugin pvio_socket could not be loaded: not initialized"QSqlQuery::exec: database not openUnable to open database "Plugin pvio_socket could not be loaded: not initialized QMYSQL: Unable to connect"
(In reply to Richard Hering from comment #6) > same here? > > (In reply to Markus from comment #5) > > downgrade does _not_ work > > Downgrading work's: akonadiserver is running fine with <mariadb-10.2 Nope. Downgrade maridb to version 10.1.25 does not help. As Markus sad, mariadb gives error during akonadi server fires up - "[ERROR] Unknown/unsupported storage engine: innodb".
Downgrading mariadb maybe helps, but the configuration changed between 10.1 and 10.2, IIRC, so also this should be downgraded. Going to try now. HOwever, the "plugin pvio_socket not loaded" is interesting.
(In reply to Brian Evans from comment #12) > This indicates MariaDB is starting and shutting down normally. So this is > something on akonadi's end. > > One major change that happened in MariaDB 10.2 is the SQL_MODE default > changed from "NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER" in 10.1 to > "NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES, > ERROR_FOR_DIVISION_BY_ZERO". > This is detailed at https://mariadb.com/kb/en/mariadb/sql-mode/ The mariadb server part seems to be starting fine. But the error: > Plugin pvio_socket could not be loaded: not initialized is an error from the mariadb client source. Also "pvio_socket" is in 10.2 but I havent found it in 10.1. akonadi is using qtsql. Did anything in the mariadb client api change?
(In reply to Markus from comment #16) > (In reply to Brian Evans from comment #12) > > This indicates MariaDB is starting and shutting down normally. So this is > > something on akonadi's end. > > > > One major change that happened in MariaDB 10.2 is the SQL_MODE default > > changed from "NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER" in 10.1 to > > "NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES, > > ERROR_FOR_DIVISION_BY_ZERO". > > This is detailed at https://mariadb.com/kb/en/mariadb/sql-mode/ > > The mariadb server part seems to be starting fine. But the error: > > Plugin pvio_socket could not be loaded: not initialized > is an error from the mariadb client source. Also "pvio_socket" is in 10.2 > but I havent found it in 10.1. > > akonadi is using qtsql. > > Did anything in the mariadb client api change? Could it be that dev-db/mysql-connector-c++ is not happy with latest mariadb?
(In reply to Fabio Coatti from comment #17) > (In reply to Markus from comment #16) > > akonadi is using qtsql. > > > > Did anything in the mariadb client api change? > > Could it be that dev-db/mysql-connector-c++ is not happy with latest mariadb? According to equery and q, qtsql is not using dev-db/mysql-connector-c++, but libmysqlclient as provided by e.g. mariadb.
Rebuilding dev-qt/qtsql-5.7.1::gentoo does not seem to have any effect. In the db_data/mysql.err logs I found this: [ERROR] InnoDB: Table `mysql`.`innodb_table_stats` not found.
(In reply to Dennis Schridde from comment #19) > In the db_data/mysql.err logs I found this: [ERROR] InnoDB: Table > `mysql`.`innodb_table_stats` not found. Running the following fixes this error, but does not help to bring back Akonadi into a functional state: /usr/sbin/mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --datadir=$HOME/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-mysql.socket mysql_upgrade --socket=/tmp/akonadi-mysql.socket kill $MYSQL_PID
After downgrading to 10.1.25 akonadi works again; I followed the procedure described here https://dev.mysql.com/doc/refman/5.6/en/downgrading.html in order to have clean datafiles. Also, I completely removed the newer mariadb files before proceeding. Now, the only thing left is to understand where is the issue :)
(In reply to PrSo from comment #14) > Nope. > Downgrade maridb to version 10.1.25 does not help. As Markus sad, mariadb > gives error during akonadi server fires up - "[ERROR] Unknown/unsupported > storage engine: innodb". Learn to downgrade mysql/mariadb: https://dev.mysql.com/doc/refman/5.7/en/downgrading.html
(In reply to Richard Hering from comment #22) > (In reply to PrSo from comment #14) > > Nope. > > Downgrade maridb to version 10.1.25 does not help. As Markus sad, mariadb > > gives error during akonadi server fires up - "[ERROR] Unknown/unsupported > > storage engine: innodb". > > Learn to downgrade mysql/mariadb: > https://dev.mysql.com/doc/refman/5.7/en/downgrading.html My apologies as it seems I didn't fully understood the proposed downgrade path. I'll test this out. Thanks.
I am also affected by this. Do you need any additional information?
More debug output by akonadi could be helpful, if someone rebuilds with USE=debug.
(In reply to Markus from comment #16) > (In reply to Brian Evans from comment #12) > > This indicates MariaDB is starting and shutting down normally. So this is > > something on akonadi's end. > > > > One major change that happened in MariaDB 10.2 is the SQL_MODE default > > changed from "NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER" in 10.1 to > > "NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES, > > ERROR_FOR_DIVISION_BY_ZERO". > > This is detailed at https://mariadb.com/kb/en/mariadb/sql-mode/ > > The mariadb server part seems to be starting fine. But the error: > > Plugin pvio_socket could not be loaded: not initialized > is an error from the mariadb client source. Also "pvio_socket" is in 10.2 > but I havent found it in 10.1. > > akonadi is using qtsql. > > Did anything in the mariadb client api change? The interesting part is that pvio_socket is a "static plugin" in mariadb-10.2.7. Perhaps this is just a bogus error message. I've tried the DBD-mysql tests which use the default socket and they mostly work. By that I mean, they get a connection via the C API and pvio_socket. Brian
Maybe the same bug, with mariadb-10.2.7 digikam segfaults on start. Downgrading to mariadb-10.1.25 helped. I've found this in the mariadb bugtracker: https://jira.mariadb.org/browse/MDEV-13317
I rebuild akonadi with the use=debug flag and here is the results: Aug 07 12:29:37 bluemeanie krunner[2590]: QObject::connect: Cannot queue arguments of type 'QMap<QString,int>' (Make sure 'QMap<QString,int>' is registered using qRegisterMetaType().) Aug 07 12:29:37 bluemeanie krunner[2590]: QObject::connect: Cannot queue arguments of type 'QMap<QString,int>' (Make sure 'QMap<QString,int>' is registered using qRegisterMetaType().) Aug 07 12:29:37 bluemeanie krunner[2590]: QObject::connect: Cannot queue arguments of type 'QMap<QString,int>' (Make sure 'QMap<QString,int>' is registered using qRegisterMetaType().) Aug 07 12:31:35 bluemeanie akonadi_control[20809]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Aug 07 12:31:35 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiprivate: search paths: ("/usr/x86_64-pc-linux-gnu/gcc-bin/6.4.0", "/usr/lib/llvm/4/bin", "/usr/local/bin", "/usr/bin", "/bin", "/opt/bin", "/opt/android-ndk", "/opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/mips64el-linux-android-4.9/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/mipsel-linux-android-4.9/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/renderscript/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/x86-4.9/prebuilt/linux-x86_64/bin", "/opt/android-ndk/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin", "/opt/android-sdk-update-manager/tools", "/opt/android-sdk-update-manager/platform-tools", "/usr/games/bin", "/opt/cuda/bin", "/opt/cuda/libnvvp", "/home/markg/bin", "/usr/bin", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/usr/share/mysql/scripts", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") Aug 07 12:31:35 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Found mysql_install_db: "" Aug 07 12:31:35 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Found mysqlcheck: "/usr/bin/mysqlcheck" Aug 07 12:31:35 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Using mysqld: "/usr/sbin/mysqld" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: mysqld reports version 10.2.7 (MariaDB) Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Executing: "/usr/sbin/mysqld" "--defaults-file=/home/markg/.local/share/akonadi/mysql.conf --datadir=/home/markg/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-markg.jNjEVG/mysql.socket --pid-file=/tmp/akonadi-markg.jNjEVG/mysql.pid" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Executing: "/usr/bin/mysqlcheck" "--defaults-file=/home/markg/.local/share/akonadi/mysql.conf --check-upgrade --auto-repair --socket=/tmp/akonadi-markg.jNjEVG/mysql.socket akonadi" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: MySQL version OK (required "5.1" , available "10.2" ) Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Database error: Cannot open database. Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: QSqlQuery::exec: database not open Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Database error: Cannot open database. Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Last driver error: "QMYSQL: Unable to connect" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Last database error: "Plugin pvio_socket could not be loaded: not initialized" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: QSqlQuery::exec: database not open Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Unable to open database "Plugin pvio_socket could not be loaded: not initialized QMYSQL: Unable to connect" Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: terminating connection threads Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: terminating service threads Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Shutting down "NotificationManager" ... Aug 07 12:31:36 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: stopping db process Aug 07 12:31:39 bluemeanie akonadiserver[20812]: org.kde.pim.akonadiserver: Shutting down AkonadiServer... Aug 07 12:31:39 bluemeanie akonadi_control[20809]: org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally... I'm happy to do any other testing.
After digging akonadi source code for a night, I finally find that the main reason cause connect fail is the QSqlDatabase::removeDatabase() call in dbconfigmysql.cpp file (line 495). I write a demo project and find if the first QSqlDatabase object removed by QSqlDatabase::removeDatabase() call, the new QSqlDatabase object create by QSqlDatabase::addDatabase() will produce the same error as this bug describe (QMYSQL: Unable to connect Plugin pvio_socket could not be loaded: not initialized). Here is the demo code: { QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", "db1"); db.setConnectOptions("UNIX_SOCKET=/tmp/akonadi-babydragon.8hNrVb/mysql.socket"); db.setDatabaseName("akonadi"); auto result = db.open(); if (result) { std::cout << "open db success" << std::endl; auto query = db.exec("show tables"); while(query.next()) { std::cout << query.value(0).toString().toStdString() << "\n"; } db.close(); } else { auto e = db.lastError(); std::cout << "open db fail! error msg: " << e.text().toStdString() << std::endl; } } QSqlDatabase::removeDatabase("db1"); std::cout << "==========="<< std::endl; { QSqlDatabase db = QSqlDatabase::addDatabase("QMYSQL", "db2"); db.setConnectOptions("UNIX_SOCKET=/tmp/akonadi-babydragon.8hNrVb/mysql.socket"); db.setDatabaseName("akonadi"); auto result = db.open(); if (result) { std::cout << "open db success" << std::endl; auto query = db.exec("show tables"); while(query.next()) { std::cout << query.value(0).toString().toStdString() << "\n"; } db.close(); } else { auto e = db.lastError(); std::cout << "open db fail! error msg: " << e.text().toStdString() << std::endl; } } But I still not find the reason why this will happen in qtsql module. The easiest way to temporary solve this problem is to commented out that line in dbconfigmysql.cpp file. --- akonadi-17.04.3/src/server/storage/dbconfigmysql.cpp 2017-08-11 23:29:02.088613966 +0800 +++ akonadi-17.04.3/src/server/storage/dbconfigmysql.cpp 2017-08-11 23:22:18.808432643 +0800 @@ -492,7 +492,7 @@ } } - QSqlDatabase::removeDatabase(initCon); + //QSqlDatabase::removeDatabase(initCon); return success; }
Thank you very much. This patch patch from comment 29 helped. Adding it to /etc/portage/patches/kde-apps/akonadi-17.04.3/ Recompiling akonadi Et voilà! (using mariadb-10.2.7-r2)
Could someone test the patch with 10.1* as well please?
(In reply to babydragon from comment #29) > After digging akonadi source code for a night, I finally find that the main > reason cause connect fail is the QSqlDatabase::removeDatabase() call in > dbconfigmysql.cpp file (line 495). > > I write a demo project and find if the first QSqlDatabase object removed by > QSqlDatabase::removeDatabase() call, the new QSqlDatabase object create by > QSqlDatabase::addDatabase() will produce the same error as this bug describe > (QMYSQL: Unable to connect Plugin pvio_socket could not be loaded: not > initialized). Did you report your findings upstream?
>=dev-db/mariadb-10.2 blocked in akonadi-17.04.3-r1 (git commit 1d7d116476c645aee82bed534ec118a9488934f2) until we have a proper fix. Thanks for investigating so far!
MariaDB 10.2.8 has been released. Can someone test if this is resolved?
Doesn't work for me, although I'm not sure it is the same issue. (kde-apps/akonadi-17.08.0:5/5::gentoo, ebuild scheduled for merge) pulled in by >=kde-apps/akonadi-17.08.0:5 required by (kde-apps/akonadi-mime-17.08.0:5/5::gentoo, ebuild scheduled for merge) >=kde-apps/akonadi-17.08.0:5 required by (kde-apps/kgpg-17.08.0:5/5::gentoo, ebuild scheduled for merge) >=kde-apps/akonadi-17.08.0:5 required by (kde-apps/akonadi-contacts-17.08.0:5/5::gentoo, ebuild scheduled for merge) (dev-db/mariadb-10.2.8:0/18::gentoo, installed) pulled in by dev-db/mariadb required by @selected =dev-db/mariadb-10.2*[embedded?,server,static?] (=dev-db/mariadb-10.2*[server]) required by (virtual/mysql-5.6-r9:0/18::gentoo, installed) dev-db/mariadb:0/18[client-libs(+),static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (dev-db/mariadb:0/18[client-libs(+),abi_x86_64(-)]) required by (virtual/libmysqlclient-18:0/18::gentoo, installed)
(In reply to Brian Evans from comment #34) > MariaDB 10.2.8 has been released. Can someone test if this is resolved? Same issue with MariaDB 10.2.8. Does a bug report upstream (Akonadi and/or MariaDB) exist? Could someone please point me to it?
See-Also: https://bugs.kde.org/show_bug.cgi?id=383991
FWIW, as a quick work-around I've just been adding --exclude kde-apps/akonadi at the end of my emerge @world commands, as I figure it will be fixed soon. Besides, I don't use any kde akonadi related stuff anyway, so never will miss it.
I found this is caused by mariadb and QtSql. The mysql_library_end() can only call once, if mysql_library_end() called, new mysql_real_connect() will rise the error "Plugin pvio_socket could not be loaded: not initialized". This is what QtSql do: QMYSQLDriver has a qMySqlConnectionCount field to count current connection, if the count equal 0, the deconstruct will call mysql_library_end(). So after first pair of QSqlDatabase::addDatabase and QSqlDatabase::removeDatabase, QSqlDatabase can never connect to mysql. For Akonadi this step is done when Akonadi try to setup mysql first time, so next time when Akonadi want to connect mysql to do real thing, this can never happen. Here is the demo code call mysql_library_end twice: https://pastebin.com/5AMT2KcP and the output is: first connect second connect connect fail: Plugin pvio_socket could not be loaded: not initialized
(In reply to babydragon from comment #39) > I found this is caused by mariadb and QtSql. The mysql_library_end() can > only call once, if mysql_library_end() called, new mysql_real_connect() will > rise the error "Plugin pvio_socket could not be loaded: not initialized". From your description and reading the documentation of mysql_library_init and mysql_library_end, it seems that this is either a regression bug in mariadb-10.2 or a documentation bug in mysql (i.e. there should be a note that this function should be called only once per program execution). In the latter case, qtsql would have to be adjusted to call mysql_library_init and mysql_library_end only once and also take care of the non-thread-safety of these functions (see the mysql documentation for details). Could you please file a bug report upstream and post the link here? Start with mariadb and then proceed to mysql + qtsql, if the mariadb maintainers reject the problem to be a regression.
Re-assigning since the error seems to be in QtSql's usage of mysql_server_end
How do we do meanwhile ? I still can't update my whole system because of this blocker : [ebuild U ] kde-apps/akonadi-17.08.1-r1 [17.08.1] USE="designer mysql xml -debug -postgres -sqlite {-test} -tools" [blocks B ] >=dev-db/mariadb-10.2 (">=dev-db/mariadb-10.2" is blocking kde-apps/akonadi-17.08.1-r1) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (dev-db/mariadb-10.2.8:0/18::gentoo, installed) pulled in by =dev-db/mariadb-10.2*[embedded?,server?,static?] (=dev-db/mariadb-10.2*[server]) required by (virtual/mysql-5.6-r9:0/18::gentoo, installed) dev-db/mariadb required by @selected dev-db/mariadb:0/18[client-libs(+),static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (dev-db/mariadb:0/18[client-libs(+),abi_x86_64(-)]) required by (virtual/libmysqlclient-18:0/18::gentoo, installed) (kde-apps/akonadi-17.08.1-r1:5/5::gentoo, ebuild scheduled for merge) pulled in by >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/eventviews-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/kgpg-17.08.1:5/5::gentoo, installed) kde-apps/akonadi:5 >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/libkdepim-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/messagelib-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/akonadi-notes-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/kdepim-apps-libs-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/calendarsupport-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/akonadi-search-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/pimcommon-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/incidenceeditor-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/akonadi-calendar-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/akonadi-mime-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/akonadi-contacts-17.08.1:5/5::gentoo, installed) >=kde-apps/akonadi-17.08.1:5 required by (kde-apps/kmailtransport-17.08.1:5/5::gentoo, installed)
(dev-db/mariadb-10.2.8:0/18::gentoo, installed) ^ that's your problem.
(In reply to Thomas Capricelli from comment #42) > How do we do meanwhile ? I still can't update my whole system because of > this blocker : Since I didn't want to downgrade my database, I installed MariaDB 10.2, modified Akonadi ebuild remove the block and applied the above patch to Akonadi — everything running fine, temporary solution until proper fix.
ok, i dont care for the mariadb version, so i can "just" locally mask >=dev-db/mariadb-10.2 Thanx ! :)
There is now a workaround in the current akonadi stable branch, see referenced bug https://bugs.kde.org/show_bug.cgi?id=383991#c4 which works well for me (tested with kde-apps/akonadi-17.08.49.9999 from the kde overlay). There also seems to be a fix for the current qt branch (5.9), see https://codereview.qt-project.org/#/c/205874/ But since gentoo still is at 5.7, that probably does not help right now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fcd29d4494974a776c442fafed0e1782d60a824d commit fcd29d4494974a776c442fafed0e1782d60a824d Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2017-09-25 13:18:26 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2017-09-25 13:18:41 +0000 dev-qt/qtsql: backport patch from upstream solving runtime failure with >=dev-db/mariadb-10.2 Bug: https://bugs.gentoo.org/626464 Package-Manager: Portage-2.3.8, Repoman-2.3.3 dev-qt/qtsql/files/qtsql-5.7.1-mariadb.patch | 56 ++++++++++++++++++++++++++++ dev-qt/qtsql/qtsql-5.7.1-r1.ebuild | 55 +++++++++++++++++++++++++++ 2 files changed, 111 insertions(+)}
The backported qtsql commit is from 5.9 branch upstream and 5.9.2 has already been branched, so I need to remember to backport it there too when released.
(In reply to Larry the Git Cow from comment #47) > commit fcd29d4494974a776c442fafed0e1782d60a824d > dev-qt/qtsql: backport patch from upstream solving runtime failure with > >=dev-db/mariadb-10.2 I updated to dev-qt/qtsql-5.7.1-r1 and am using dev-db/mariadb-10.2.8, but still Akonadi does not start, instead logging the same error related to pvio_socket. Do I need to do something in addition to upgrading qtsql to r1, to get the fix?
Interesting. Alternatively, akonadi 17.08 branch has a workaround: https://cgit.kde.org/akonadi.git/commit/?h=Applications/17.08&id=b145f47f000978b9d39edc1882849ec7f6b3ef79
(In reply to Andreas Sturmlechner from comment #50) > Interesting. Alternatively, akonadi 17.08 branch has a workaround: > https://cgit.kde.org/akonadi.git/commit/?h=Applications/17. > 08&id=b145f47f000978b9d39edc1882849ec7f6b3ef79 Putting that patch into /etc/portage/patches and rebuilding akonadi had the desired effect: Akonadi starts again.
Thanks for testing.
17.08.2 added to tree in a6d3a93f1f50f5797b4d119f529dffcaf0d3a1e4
