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
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.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
