Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 709812 - kde-apps/akonadi-{19.08.3,19.12.2} with dev-db/mysql-8.0.19{-r1} - error: 'Can't connect to local MySQL server through socket '/run/user/1000/akonadi/mysql.socket' (2)'
Summary: kde-apps/akonadi-{19.08.3,19.12.2} with dev-db/mysql-8.0.19{-r1} - error: 'Ca...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-16 15:14 UTC by Stephan Karacson
Modified: 2020-03-05 21:04 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/home/manfred/.local/share/akonadi/mysql.conf (mysql.conf,3.34 KB, text/plain)
2020-02-16 16:01 UTC, Manfred Knick
Details
~/.local/share/akonadi/db_data/mysql.err (mysql.err,1.25 KB, text/plain)
2020-02-16 16:11 UTC, Manfred Knick
Details
~/.local/share/akonadi/db_data (file_709812.txt,1.22 KB, text/plain)
2020-02-16 19:37 UTC, Luis Ferreira
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Karacson 2020-02-16 15:14:26 UTC
akonadi-19.08.3 (whole kdepim doesnt work since update)

I tried to rebuild database (delete ~/.local/share/akonadi/ ~/.config/akonadi/ ~/.config/akonadi*) 

Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection!
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/USER/.local/share/akonadi/mysql.conf", "--datadir=/home/USER/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: ""
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/run/user/1000/akonadi/mysql.socket' (2)'
Check that mysqld is running and that the socket: '/run/user/1000/akonadi/mysql.socket' exists!
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

reemerge akonadi* and qtsql with new mysql doesn't work

=dev-db/mysql-8.0.19-r1
=dev-db/mysql-connector-c-8.0.19
=dev-db/mariadb-connector-c-3.1.6
in package.mask works with resetting (delete folders) akodai-files again.

Now adding recources one by one...
Comment 1 Manfred Knick 2020-02-16 15:17:29 UTC
REFERENCE:  https://bugs.gentoo.org/709624#c2
Comment 2 Thomas Deutschmann gentoo-dev Security 2020-02-16 15:33:20 UTC
Looks like you are not running a normal mysqld. Instead you are running an own instance for akonadi (I don't know akonadi).

Make sure that this server configuration is compatible with MySQL v8. When mysqld starts, you will get some logs (normally in /var/log/mysql... but when using an own configuration like your do, see --defaults-file=... your path could be different, according to Google search, it maybe '~/.local/share/akonadi/db_data/mysql.err').

Hopefully the CFG is just incompatible and mysqld-8 rejects to start.
Comment 3 Manfred Knick 2020-02-16 15:54:09 UTC
Completely deleting ~/.config/akonadi* and ~/.local/share/akonadi* :

$ akonadictl start 

Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)

org.kde.pim.akonadiserver: Starting up the Akonadi Server...

2020-02-16T15:48:58.722252Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8161)
2020-02-16T15:48:58.722258Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 431 (requested 4000)

2020-02-16T15:48:58.722516Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.19) initializing of server in progress as process 2672
2020-02-16T15:49:02.642998Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: nihnvGb9##2H

org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection!
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/manfred/.local/share/akonadi/mysql.conf", "--datadir=/home/manfred/.local/share/akonadi/db_data/", "--socket=/run/user/1111/akonadi/mysql.socket", "--pid-file=/run/user/1111/akonadi/mysql.pid")

org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: ""
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"

mysqladmin: connect to server at 'localhost' failed

error: 'Can't connect to local MySQL server through socket '/run/user/1111/akonadi/mysql.socket' (2)'
Check that mysqld is running and that the socket: '/run/user/1111/akonadi/mysql.socket' exists!

org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...


The error message is correct:

$ lla     /run/user/1111/akonadi/                        <---! empty
insgesamt 0
drwxr-xr-x 2 manfred manfred  40 16. Feb 11:56 .
drwx------ 5 manfred manfred 140 16. Feb 11:40 ..

Two of the files mentioned as arguments have not been created.
Comment 4 Thomas Deutschmann gentoo-dev Security 2020-02-16 15:59:15 UTC
This doesn't help. Of course, in the end, akonadi will fail, because mysqld didn't start and therefore didn't create PID file or socket.

The question is *why* did the mysql instance from akonadi fail to start?

Two important things:
Mysql-8 is a new major release. Some config options from previous versions are no longer valid and mysqld will reject to start when these parameters are present. The error log will tell you about that.

I don't know what you mean with "I delete database". From my understanding, you cleaned akonadi's mysql data dir. If this is the case you can't just start mysql again. You will first have to re-initialize that data dir. I can't tell you how to to that.


tl;dr
Please find akonadi's mysqld error log and show us its content.
Comment 5 Manfred Knick 2020-02-16 16:01:26 UTC
Created attachment 614034 [details]
/home/manfred/.local/share/akonadi/mysql.conf

~/.local/share $ ll akonadi/mysql.conf akonadi/db_data/ 

-rw-r--r-- 1 manfred manfred 3,4K 16. Feb 16:48 akonadi/mysql.conf

akonadi/db_data/:

insgesamt 185M

-rw-r----- 1 manfred manfred   56 16. Feb 16:49  auto.cnf
-rw-r----- 1 manfred manfred    0 16. Feb 16:49  binlog.index
-rw------- 1 manfred manfred 1,7K 16. Feb 16:49  ca-key.pem
-rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49  ca.pem
-rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49  client-cert.pem
-rw------- 1 manfred manfred 1,7K 16. Feb 16:49  client-key.pem
-rw-r----- 1 manfred manfred 5,7K 16. Feb 16:49  ib_buffer_pool
-rw-r----- 1 manfred manfred  12M 16. Feb 16:49  ibdata1
-rw-r----- 1 manfred manfred  64M 16. Feb 16:49  ib_logfile0
-rw-r----- 1 manfred manfred  64M 16. Feb 16:49  ib_logfile1
drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49 '#innodb_temp'
drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49  mysql
-rw-r----- 1 manfred manfred 1,3K 16. Feb 16:49  mysql.err
-rw-r----- 1 manfred manfred  24M 16. Feb 16:49  mysql.ibd
drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49  performance_schema
-rw------- 1 manfred manfred 1,7K 16. Feb 16:49  private_key.pem
-rw-r--r-- 1 manfred manfred  452 16. Feb 16:49  public_key.pem
-rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49  server-cert.pem
-rw------- 1 manfred manfred 1,7K 16. Feb 16:49  server-key.pem
drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49  sys
-rw-r----- 1 manfred manfred  10M 16. Feb 16:49  undo_001
-rw-r----- 1 manfred manfred  10M 16. Feb 16:49  undo_002
Comment 6 Manfred Knick 2020-02-16 16:11:06 UTC
Created attachment 614036 [details]
~/.local/share/akonadi/db_data/mysql.err

HTH:

2020-02-16T15:49:08.304474Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0').

2020-02-16T15:49:08.304799Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.

2020-02-16T15:49:08.305056Z 0 [ERROR] [MY-010119] [Server] Aborting
Comment 7 Thomas Deutschmann gentoo-dev Security 2020-02-16 16:17:07 UTC
If you rely on lower_case_table_names, this option must be already set during initialization. It cannot be set afterwards, see https://bugs.mysql.com/bug.php?id=90814. Like said, I don't know akonadi but I would try to get rid of lower_case_table_names from mysql.conf if possible.
Comment 8 Andreas Sturmlechner gentoo-dev 2020-02-16 16:24:10 UTC
Is this a change in defaults by mysql or a remainder of a past workaround?

For reference:
https://bugs.kde.org/show_bug.cgi?id=409753#c4
https://bugs.kde.org/show_bug.cgi?id=409234

Supposedly fixed in:
https://cgit.kde.org/akonadi.git/commit/?id=8b8db29d10b2ef92deb2d87ff613f3d7f39af34e
Comment 9 Thomas Deutschmann gentoo-dev Security 2020-02-16 16:28:01 UTC
Mysql-8 is stricter. It will recognize that you didn't initialize data dir with this option set and therefore rejects to start. See the linked mysql bug: If you need that option, you must set it already during initialization. You cannot cahnge after initialization.
Comment 10 Luis Ferreira 2020-02-16 19:37:36 UTC
Created attachment 614068 [details]
~/.local/share/akonadi/db_data
Comment 11 Manfred Knick 2020-02-16 20:40:15 UTC
(In reply to Luis Ferreira from comment #10)
> Created attachment 614068 [details]
> ~/.local/share/akonadi/db_data
--> unknown variable 'log_warnings=2'

Good point - missed that one
Comment 12 Stephan Karacson 2020-02-16 21:42:02 UTC
I'm using kde straight in gentoo since version 2.
I did never set up a mysql-server.
I am an mysql-auto-configuration-user.

Introducing akonadi, kde started using mysql with an auto-configurated local instance.

Upgrading a major version, I usually stop akonadi (akonadictl stop), upgrade kdepim and/or mysql and start akonadi again.
If migration of akonadi/mysql data fails, the deletion of the akonadi-cache or in the end the whole reset (delete akonadi-files, see my first comment) should be sufficient.
In my case it did fail too.
Downgrade worked.
My amateurish conclusion: akonadi-19.08.3 autoconfiguration of local mysqld-instance can't handle mysql-8 yet?

As akonadi uses mysql for working with data, but not as a place the data itself, there is no real loss of data for me.
But it is a (for a private user) hell of work to set it up all again...
Comment 13 Manfred Knick 2020-02-17 12:14:36 UTC
(In reply to Stephan Karacson from comment #12)
> ... akonadi-19.08.3 ...
..............^^.^^.^

[IP-] [  ] kde-apps/akonadi-19.12.2:5    et al.


TEST:

# grep mysql /etc/portage/package.mask

>=dev-db/mysql-8.0.0:0          # 709812
--> Downgrade dev-db/mysql to

[IP-] [  ] dev-db/mysql-5.7.29:0/18


Afterwards,
a) starting kaddressbook works,
   including implicit akonadi start,
   but no entries show up as AdressBook Name entries.
b) Confirming "/home/manfred/.local/share/contacts/"
   in AdressBook Properties dialog,
   stop KAddressBook
c) start KAddressBook again:
   now entries show up as expected.

RESUMEE: Observations fit to suspected causation.

Thanks @ Thomas! (comment #7)
Comment 14 Manfred Knick 2020-02-17 17:10:23 UTC
WORKAROUND:

- disable ">=dev-db/mysql-8.0.0:0" package mask <--- in case you entered one

- un-merge   dev-db/mysql-5.7.29:0/18      <--- no need to unmerge -8.0.19-r1

         !!! ONLY -if you have no separate db instances !!!
- delete     mysql data directory at '/var/lib/mysql'
         !!! ONLY -if you have no separate db instances !!!

- emerge     dev-db/mysql-8.0.19-r1:0
- emerge   --config =dev-db/mysql-8.0.19-r1
- >          select "caching_sha2_password"
- >          provide a password for the mysql 'root' user

- rm -r      ~/.config/akonadi*
- rm -r      ~/.local/share/akonadi*

$ akonadictl start --verbose  <--- this will fail, as expected, but
                              <--- populize ~/.config/          and
                              <--- populize ~/.local/share/

$ rm -r      ~/.local/share/akonadi/db_data      (or move it, for comparison)
$ mkdir      ~/.local/share/akonadi/db_data      (empty, to be initialized)

$ edit       ~/.local/share/akonadi/mysql.conf :

                # log_warnings=2                   # (unknown)

                lower_case_table_names=0           # (=1 does not work)

                # query_cache_size=0               # (unknown)
                # query_cache_type=0               # (unknown)

$ akonadictl start --verbose  <--- this time will start up and
                              <--- thereby initialize the empty db_data a-new

- start KAddressBook
- end   KAddressBook
- start KAddressBook again
- >     enable your AdressBook    <--- this time you should see your entries

HTH.
Comment 15 Manfred Knick 2020-02-17 17:21:28 UTC
(ADDENDUM to comment #14)
> - emerge     dev-db/mysql-8.0.19-r1:0
Of course, this is only needed if you had previously fallen back to -5.7.29;
no need to re-emerge the identical package;
just continue with the following "--config" step.
Comment 16 Stephan Karacson 2020-02-18 10:54:34 UTC
Currently I have to look having time to do this workaround. Seems I have to reorganize all akonadi-recources again. And I still not get why I have to configure mysql with a root-password, as akonadi makes its own and so there is no /var/lib/mysql (you see I'm no developer). Anyway this workaround seems to be a great help.

Please tell me if I'm wrong, but you have to do this workaround every time akonadi is making a new db or clean it (for example after an broken upgrade of kdepim, a new install, a new kde-user...).

I'm not from the gentoo-team, but current stable akonadi seems not to "initialize data dir with this option" (Thomas). So shouldn't akonadis ebuild depend on maximum mysql-5.7.x until it can handle the case?
Comment 17 Thomas Deutschmann gentoo-dev Security 2020-02-18 15:22:59 UTC
(In reply to Stephan Karacson from comment #16)
> Currently I have to look having time to do this workaround. Seems I have to
> reorganize all akonadi-recources again. And I still not get why I have to
> configure mysql with a root-password, as akonadi makes its own and so there
> is no /var/lib/mysql (you see I'm no developer). Anyway this workaround
> seems to be a great help.

If akonadi really uses its own data dir, running `emerge --config dev-db/mysql` should be pointless.


> I'm not from the gentoo-team, but current stable akonadi seems not to
> "initialize data dir with this option" (Thomas). So shouldn't akonadis
> ebuild depend on maximum mysql-5.7.x until it can handle the case?

Sure, this is one way to handle this if akonadi can't be fixed to work with mysql-8.
Comment 18 Manfred Knick 2020-02-18 16:33:06 UTC
(In reply to Stephan Karacson from comment #16)

In WORKAROUND, my intention was to re-set to a "clean new (8.0) track"
for other (non-akonadi) applications not to be limited by old (< 2003) initial setups.

Anybody who is only interested in akonadi should feel free to simply mask 
>=8.0 as already demonstrated / tested in my earlier comment #13.

Please, grant the KDE team sufficient time to sort things out properly; e.g.

@ Andreas:  Any fallout to be expected when adding restrictions into an 
akonadi-19.12.2-r1.ebuild (RDEPEND: lines 63..64),
esp. for those who have already run the update, 
then forcibly being switched back to mysql-5.7 again?

Currently, here on x86_64:

# equery list -p virtual/mysql
[-P-] [ ~] virtual/mysql-5.5-r2:0
[IP-] [  ] virtual/mysql-5.6-r13:0/18                            <---

# grep "mysql-\${PV}" /usr/portage/virtual/mysql/mysql*.ebuild

.../mysql-5.5-r2.ebuild:
      =dev-db/mysql-${PV}*[static?,static-libs(-)?]

.../mysql-5.6-r13.ebuild:
     >=dev-db/mysql-${PV}[embedded(-)?,server?,static(-)?]       <---

.....^.....

@ Thomas:
Would it make sense to limit virtual/mysql-5.6-r13:0/18
and to introduce a new virtual/mysql-8.0 ?
Comment 19 Robert Schedel 2020-03-05 21:04:50 UTC
For me, mysql.err indicated that content of /etc/xdg/akonadi/mysql-global.conf was used, and some of its obsolete flags were regarded as fatal error now by mysql.

By uncommenting those three flag below

 #log_warnings=2
 #query_cache_size=0
 #query_cache_type=0

and restarting with "akonadictl start", all was working again.
This seems simpler than previous comment 14, particularly if no .local conf files exists, i.e. if the /etc/xdg/akonadi/mysql-global*.conf templates are used.

According to "equery belongs", those files are installed by "kde-apps/akonadi-19.2.2". For testing, also deleted the original etc files and reinstalled "kde-apps/akonadi", hoping for an upstream version with mysql8 support, but they are still insufficient.

Would be interesting if this simple three line patch works also for others, because could also be applied as patch on "kde-apps/akonadi".

But safest obviously is to avoid mysql8 and wait for akonadi upstream fix.