Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6

[Peter Humphrey]

On Wednesday, 10 July 2019 18:40:04 BST Mick wrote:
> On Wednesday, 10 July 2019 14:31:19 BST Peter Humphrey wrote:
> > On Wednesday, 10 July 2019 10:06:01 BST Peter Humphrey wrote:
> > > On Wednesday, 10 July 2019 00:06:43 BST Adam Carter wrote:
> > > > > I've just tried upgrading mariadb again while watching it, and got
> > > > > similar
> > > > > results. I did notice that an error notice came up about being
> > > > > unable
> > > > > to
> > > > > store
> > > > > a message received via POP3, which is my main incoming source. I
> > > > > can't
> > > > > quote
> > > > > exactly because the notice disappeared too soon.
> > > > >
> > > > > Back to 10.3.16 for now.
> > > >
> > > > Just to confirm, when you say upgrade you mean something like;
> > > > emerge -u mariadb
> > > > systemctl restart mariadb
> > > > mysql_upgrade -u root -p
> > >
> > > Akonadi runs an instance of mariadb for its own use, without reference
> > > to
> > > what else might be running on the machine.
> > >
> > > I've never had to run mysql_upgrade before, and I can't find a way to do
> > > it
> > > manually because of this in .local/share/akonadi/mysql.conf:
> > >
> > > # Do not listen for TCP/IP connections at all
> > > skip_networking
> > >
> > > Maybe I could comment that out temporarily, but I don't know what else
> > > might be affected. Otherwise it looks like creating a new user for
> > > myself
> > > and importing the message archive.
> >
> > Well, I tried that but when I started kmail to set it up again, it crashed
> > after telling me it had failed to get a lock. On what, it didn't say.
>
> /usr/bin/akonadi_control launches /usr/bin/akonadiserver, which lunches
> /usr/ sbin/mysqld:
>
> /usr/bin/akonadi_control
>
>  \_ /usr/bin/akonadiserver
>
>      \_/usr/sbin/mysqld
>
> They're all running as the user who launches kmail, i.e. yourself.  Also,
> unless you have tweaked access to the database to allow TCP, it will only
> use a local Unix socket.  Have a look in your /tmp fs for this socket name.
>  If your kdepim user is logged in as user 'peter', I'm guessing you'll see
> something like this, as long as akonadiserver is running:
>
> /tmp/akonadi-peter.XXXXXX/mysql.socket
>
> You could try running mysql_upgrade on this, but the command will request
> access to default mysql database tables and its socket under
> /var/run/mysqld/, which I assume you won't be running unnecessarily just
> for a Plasma/KDE desktop.  Consequently the incantation will fail.
>
> Instead, you could try running the individual commands mysql_upgrade runs
> yourself, only on the akonadi tables.  Here's my attempt:
>
> $ /usr/bin/mysqlcheck -u michael --all-databases --check-upgrade
> --auto-repair --socket=/tmp/akonadi-michael.ZtUWTD/mysql.socket
> 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

$ /usr/bin/mysqlcheck -u prh --all-databases --check-upgrade --auto-repair --
socket=/tmp/akonadi-prh.1l0Gu6/mysql.socket
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

That's on the older version of mariadb. I'll try it again with my new user and 
the new mariadb.

> Or, you could connect to the above socket with /usr/bin/mysql and run SQL
> commands from within, after you select each akonadi database/table in turn.
>
> Normally, I don't think any of the above is required.  From what I recall
> akonadiserver runs mysql_upgrade each and every time akonadiserver is
> launched.  However, if akonadi can't run the kdepim mysql following a
> database version update, then you'll need to look deeper into it.
>
> If akonadiserver does not start/crashes, it may be more effective to look at
> the mysql.err logs under  ~/.local/share/akonadi/db_data/.
>
> You could also launch akonadiconsole, switch on debugging and see if it
> offers anything more informative when you try to restart akonadi.
>
> HTH.

Certainly does! Many thanks Mick.

-- 
Regards,
Peter.