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.
