Pourquoi Akonadi ne démarre-t-il pas après la mise à niveau d'Ubuntu 19.04 vers 19.10?
J'ai mis à jour Ubuntu 19.04 vers 19.10 et Akonadi (5.11.3) ne démarre pas après le redémarrage. Lorsque j'essaie de démarrer le serveur akonadi dans la ligne de commande, voici ce que j'obtiens:
~ $ akonadictl start
Connexion au signal obsolète QDBusConnectionInterface :: serviceOwnerChanged (QString, QString, QString)
org.kde.pim.akonadiserver: Démarrage du serveur Akonadi ...
org.kde.pim.akonadiserver: le serveur de base de données s'est arrêté de manière inattendue
org.kde.pim.akonadiserver: Le processus de base de données s'est arrêté de manière inattendue lors de la connexion initiale! org.kde.pim.akonadiserver: exécutable: "/ usr/sbin/mysqld-akonadi" org.kde.pim.akonadiserver: arguments: ("--defaults-file =/home/me/.local/share/akonadi/mysql.conf "," --datadir =/home/me/.local/share/akonadi/db_data/"," --socket =/run/user/1001/akonadi/default/mysql.socket "," - pid-file =/run/user/1001/akonadi/default/mysql.pid ")
org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "" org.kde.pim.akonadiserver: code de sortie: 1
org.kde.pim.akonadiserver: erreur de processus: "Erreur inconnue" mysqladmin: connexion au serveur à 'localhost' a échoué erreur: 'Impossible de se connecter au serveur MySQL local via socket'/run/user/1001/akonadi/default/mysql.socket '(2)' Vérifiez que mysqld fonctionne et que la socket: '/run/user/1001/akonadi/default/mysql.socket' existe!
org.kde.pim.akonadiserver: échec de la suppression du fichier de configuration de la connexion d'exécution org.kde.pim.akonadiserver: arrêt d'AkonadiServer ...
Je vérifie le fichier mysql.err avec l'entrée suivante.
~ $ chat ~/.local/share/akonadi/db_data/mysql.err
2019-10-19T11: 27: 02.910707Z 0 [Avertissement] [MY-010097] [Serveur] Configuration non sécurisée pour --secure-file-priv: La valeur actuelle ne limite pas l'emplacement des fichiers générés. Pensez à le définir sur un chemin valide et non vide.
2019-10-19T11: 27: 02.910736Z 0 [Système] [MY-010116] [Serveur]/usr/sbin/mysqld (mysqld 8.0.17-0ubuntu2) commençant en tant que processus 8385
2019-10-19T11: 27: 02.912513Z 0 [Avertissement] [MY-013242] [Serveur] --character-set-server: 'utf8' est actuellement un alias pour le jeu de caractères UTF8MB3, mais sera un alias pour UTF8MB4 dans une future version. Veuillez envisager d'utiliser UTF8MB4 afin d'être sans ambiguïté.
2019-10-19T11: 27: 02.912523Z 0 [Avertissement] [MY-013244] [Serveur] --collation-server: 'utf8_general_ci' est un assemblage du jeu de caractères obsolète UTF8MB3. Veuillez envisager d'utiliser UTF8MB4 avec un classement approprié à la place. 2019-10-19T11: 27: 02.917836Z 1 [Système] [MY-011012] [Serveur] Démarrage de la mise à niveau du répertoire de données.
2019-10-19T11: 27: 03.171213Z 1 [ERREUR] [MY-010781] [Serveur] Fichier ./mysql/index_stats.frm trouvé dans le schéma mysql. DD créera un fichier .ibd avec le même nom. Veuillez renommer la table et recommencer le processus de mise à niveau.
2019-10-19T11: 27: 03.171223Z 1 [ERREUR] [MY-010336] [Serveur] Fichier .frm trouvé avec le même nom que l'une des tables de dictionnaire.
2019-10-19T11: 27: 03.171330Z 0 [ERREUR] [MY-010020] [Serveur] L'initialisation du dictionnaire de données a échoué.
2019-10-19T11: 27: 03.171338Z 0 [ERREUR] [MY-013236] [Serveur] Le répertoire de données désigné /home/me/.local/share/akonadi/db_data/ est inutilisable. Vous pouvez supprimer tous les fichiers que le serveur y a ajoutés.
2019-10-19T11: 27: 03.697829Z 0 [ERREUR] [MY-010065] [Serveur] Échec de l'arrêt de l'infrastructure des composants.
2019-10-19T11: 27: 03.171475Z 0 [ERREUR] [MY-010119] [Serveur] Abandon
2019-10-19T11: 27: 03.697752Z 0 [Système] [MY-010910] [Serveur]/usr/sbin/mysqld: Arrêt terminé (mysqld 8.0.17-0ubuntu2) (Ubuntu).
Pourquoi Akonadi ne démarre pas après la mise à niveau d'Ubuntu 19.04 vers 19.10? Est-ce lié à la mise à niveau vers mysql 8.0? Comment résoudre ce problème?
la mariadb devrait maintenant être utilisée. mysql 8 n'est pas compatible.
Sudo apt install mariadb-server-core-10.3 mariadb-client-core-10.3
Obtenir le même problème, akonadi ne fonctionne pas à cause de MySQL après la mise à niveau. Pour moi, l'installation de MariaDB n'est pas une option, à cause de mon travail. J'utilisais MariaDB avant et j'ai dû passer à MySQL.
1 │ 2019-11-17T22:14:02.183446Z 0 [Warning] [MY-010097] [Server] Insecure configuration for --secure-file-priv: C
│ urrent value does not restrict location of generated files. Consider setting it to a valid, non-empty path.
2 │ 2019-11-17T22:14:02.183483Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.17-0ubuntu2) startin
│ g as process 30942
3 │ 2019-11-17T22:14:02.186416Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an a
│ lias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider usi
│ ng UTF8MB4 in order to be unambiguous.
4 │ 2019-11-17T22:14:02.186429Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a colla
│ tion of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation ins
│ tead.
5 │ 2019-11-17T22:14:02.194794Z 1 [ERROR] [MY-011011] [Server] Failed to find valid data directory.
6 │ 2019-11-17T22:14:02.194929Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
7 │ 2019-11-17T22:14:02.195077Z 0 [ERROR] [MY-010119] [Server] Aborting
8 │ 2019-11-17T22:14:02.195315Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.1
│ 7-0ubuntu2) (Ubuntu).
Ce sont l'erreur et les avertissements que je reçois.
Le premier supprimera les avertissements bruyants vim /home/mathieu/.local/share/akonadi/mysql.conf
remplacer character_set_server=utf8 pour devenir utf8mb4 commenter collation_server= selon ce document, la valeur par défaut est bonne https://dev.mysql.com/doc/refman/8.0/en/charset-server.html
Je ne pense pas que nous puissions faire quoi que ce soit secure_file_priv= Je crois que akonadi a besoin qu'il soit vide pour pouvoir charger des fichiers à partir d'emplacements arbitraires. doc: https://dev.mysql.com/doc/refman/8.0/en/string-functions.html
puis, l'erreur réelle Failed to find valid data directory
comme akonadi est principalement des données temporaires, je pense que le plus simple est de tuer le répertoire db_data et de recommencer. nous renommerons le dossier au lieu de le supprimer
$ cd ~/.local/share/akonadi
$ mv db_data db_databkp
$ mkdir db_data
$ /usr/sbin/mysqld-akonadi --defaults-file=/home/mathieu/.local/share/akonadi/mysql.conf --datadir=/home/mathieu/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/default/mysql.socket --pid-file=/run/user/1000/akonadi/default/mysql.pid --initialize --console
le --initialize l'option démarre le db_data dir frais. si vous comparez les deux dir, vous verrez un tas de fichiers différents du précédent.
obtenir maintenant cette erreur
[ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0').
Je change cette option lower_case_table_names= dans mysql.conf de 1 à 0
vous devez également commenter cette option obsolète
log_warnings=2
Je n'appelle plus mysqld-akonadi directement, avec le long ensemble d'arguments, mais simplement en exécutant akonadiserver et cating le fichier journal mysql.error
obtenir cette erreur maintenant [Server] unknown variable 'query_cache_size=0'
commentera celui-ci
également besoin de commenter query_cache_type=0
et akonadi est capable de fonctionner avec MySQL 8
En résumé:
- utf8 à utf8mb4 est un bon changement, laisser les deux en commentaire est la nouvelle valeur par défaut
- commenter les 4 options obsolètes
- éloignez votre ancien répertoire db_data, créez un répertoire vide à la place
- redémarrer akonadiserver
J'espère que cela t'aides
Mise à jour: si vous obtenez cette erreur
org.kde.pim.akonadiserver: Running DB initializer
org.kde.pim.akonadiserver: "\nSql error: Duplicate column name 'version' QMYSQL: Unable to execute query\nQuery: ALTER TABLE SchemaVersionTable ADD COLUMN version INTEGER NOT NULL DEFAULT 0"
cela signifie que la colonne a déjà été ajoutée, mais la migration de la base de données n'a pas été marquée comme terminée. Je recommanderais de tuer le db_data dossier à nouveau, en exécutant l'initialisation manuellement. et démarrer akonadiserver
sa course enfin pour moi. et korganizer qui plantait constamment en 19.04 fonctionne maintenant;)
Mise à jour (2020): faites très attention à ce bogue lors de la réinitialisation de votre base de données Akonadi https://bugs.kde.org/show_bug.cgi?id=4144
Depuis 19.10, j'ai eu trop de problèmes. Ni MariaDB ni MySQL 8 n'ont bien fonctionné. J'ai dû réinitialiser Akonadi. Enfin exécuté MySQL 5.6 et 5.7 via Docker
Sudo docker run --name mysql57 --rm -p 3306:3306 -v /var/lib/mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=docker -d mysql:5.7
mais continuait à avoir des problèmes. J'ai abandonné Akonadi/kdepim, désinstallé tous les packages associés et basculé vers Thunderbird. Le plasma fonctionne bien.
J'ai également eu des problèmes avec Akonadi depuis la mise à jour de Kubuntu 19.04 à 19.10. Le fichier journal mysql ~/.local/share/akonadi/db_data/mysql.err contenait des erreurs comme:
unknown variable 'log-warnings=2'
J'ai donc commenté ceux-ci dans /home/NNN/.local/share/akonadi/mysql.conf:
# print warnings and connection errors (default:1)
#log_warnings=2
.
.
# Memory allocated for caching query results (default:0 (disabled))
#query_cache_size=0
. .
# Do not cache results (default:1)
#query_cache_type=0
Pour être honnête, je m'en fichais, quelles variables ont été modifiées et quelles en seraient les conséquences ...
L'erreur indique qu'il existe une table utilisateur dans MySQL avec le nom index_stats ce qui semble étrange. Sauf si vous ou l'un des programmes que vous utilisez avez créé cette table.
En d'autres termes, vous ne pouvez plus avoir de tables avec ce nom car MySQL 8.0 utilise une table avec ce nom.
Vous pouvez essayer de renommer le fichier en quelque chose comme index_stats_bak.frm mais il est difficile de dire ce qui arrivera à n'importe quel programme qui l'utilise.
Cet article a une liste de noms de table qui sont maintenant utilisés par le système, index_stats parmi eux.
En regardant source pour Akonadi qui crée des tables, il semble très peu probable qu'il y ait un conflit avec MySQL 8. Je suppose qu'il y a eu une mise à niveau partielle de MySQL qui a laissé la partie des nouvelles tables mais pas tout. index_stats a probablement été créé dans cette mise à jour partielle.