it-swarm.com.de

Warum startet Akonadi nach dem Upgrade von Ubuntu 19.04 auf 19.10 nicht?

Ich habe Ubuntu 19.04 auf 19.10 aktualisiert und Akonadi (5.11.3) startet nach dem Neustart nicht. Wenn ich versuche, den Akonadi-Server in der Befehlszeile zu starten, erhalte ich Folgendes:

~ $ akonadictl start

Verbindung zum veralteten Signal herstellen QDBusConnectionInterface :: serviceOwnerChanged (QString, QString, QString)

org.kde.pim.akonadiserver: Starten des Akonadi-Servers ...

org.kde.pim.akonadiserver: Datenbankserver wurde unerwartet gestoppt

org.kde.pim.akonadiserver: Der Datenbankprozess wurde während der ersten Verbindung unerwartet beendet! org.kde.pim.akonadiserver: ausführbar: "/ usr/sbin/mysqld-akonadi" org.kde.pim.akonadiserver: Argumente: ("--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: Exit-Code: 1

org.kde.pim.akonadiserver: Prozessfehler: "Unbekannter Fehler" mysqladmin: Verbindung zum Server bei 'localhost' fehlgeschlagen Fehler: 'Verbindung zum lokalen MySQL-Server über Socket nicht möglich'/run/user/1001/akonadi/default/mysql.socket '(2)' Überprüfen Sie, ob mysqld ausgeführt wird und ob der Socket '/run/user/1001/akonadi/default/mysql.socket' vorhanden ist!

org.kde.pim.akonadiserver: Fehler beim Entfernen der Konfigurationsdatei für die Laufzeitverbindung org.kde.pim.akonadiserver: Herunterfahren von AkonadiServer ...

Ich überprüfe die Datei mysql.err mit der folgenden Eingabe.

~ $ cat ~/.local/share/akonadi/db_data/mysql.err

2019-10-19T11: 27: 02.910707Z 0 [Warnung] [MY-010097] [Server] Unsichere Konfiguration für --secure-file-priv: Der aktuelle Wert schränkt den Speicherort der generierten Dateien nicht ein. Stellen Sie einen gültigen, nicht leeren Pfad ein.

2019-10-19T11: 27: 02.910736Z 0 [System] [MY-010116] [Server]/usr/sbin/mysqld (mysqld 8.0.17-0ubuntu2) wird als Prozess 8385 gestartet

2019-10-19T11: 27: 02.912513Z 0 [Warnung] [MY-013242] [Server] --character-set-server: 'utf8' ist derzeit ein Alias ​​für den Zeichensatz UTF8MB3, wird jedoch ein Alias ​​für UTF8MB4 sein in einer zukünftigen Version. Bitte erwägen Sie die Verwendung von UTF8MB4, um eindeutig zu sein.

2019-10-19T11: 27: 02.912523Z 0 [Warnung] [MY-013244] [Server] --collation-server: 'utf8_general_ci' ist eine Zusammenstellung des veralteten Zeichensatzes UTF8MB3. Bitte verwenden Sie stattdessen UTF8MB4 mit einer geeigneten Sortierung. 2019-10-19T11: 27: 02.917836Z 1 [System] [MY-011012] [Server] Aktualisierung des Datenverzeichnisses wird gestartet.

2019-10-19T11: 27: 03.171213Z 1 [FEHLER] [MY-010781] [Server] Die Datei ./mysql/index_stats.frm wurde im MySQL-Schema gefunden. DD erstellt eine .ibd-Datei mit demselben Namen. Bitte benennen Sie die Tabelle um und starten Sie den Upgrade-Vorgang erneut.

2019-10-19T11: 27: 03.171223Z 1 [FEHLER] [MY-010336] [Server] .frm-Datei mit demselben Namen wie eine der Wörterbuchtabellen gefunden.

2019-10-19T11: 27: 03.171330Z 0 [FEHLER] [MY-010020] [Server] Die Initialisierung des Datenwörterbuchs ist fehlgeschlagen.

2019-10-19T11: 27: 03.171338Z 0 [FEHLER] [MY-013236] [Server] Das angegebene Datenverzeichnis /home/me/.local/share/akonadi/db_data/ ist unbrauchbar. Sie können alle Dateien entfernen, die der Server hinzugefügt hat.

2019-10-19T11: 27: 03.697829Z 0 [FEHLER] [MY-010065] [Server] Fehler beim Herunterfahren der Komponenteninfrastruktur.

2019-10-19T11: 27: 03.171475Z 0 [FEHLER] [MY-010119] [Server] Abbruch

2019-10-19T11: 27: 03.697752Z 0 [System] [MY-010910] [Server]/usr/sbin/mysqld: Herunterfahren abgeschlossen (mysqld 8.0.17-0ubuntu2) (Ubuntu).

Warum startet Akonadi nach dem Upgrade von Ubuntu 19.04 auf 19.10 nicht? Ist dies mit dem Upgrade auf MySQL 8.0 verbunden? Wie kann das gelöst werden?

2
Eduard

mariadb sollte jetzt verwendet werden. MySQL 8 ist nicht kompatibel.

Sudo apt install mariadb-server-core-10.3 mariadb-client-core-10.3
2
BrianH

Akonadi wird nach dem Upgrade aufgrund von MySQL nicht ausgeführt. Für mich ist die Installation von MariaDB aufgrund meiner Arbeit keine Option. Ich habe MariaDB schon einmal benutzt und musste zu MySQL wechseln.

   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).

Dies sind die Fehler und Warnungen, die ich erhalte.

Zuerst werden laute Warnungen entfernt vim /home/mathieu/.local/share/akonadi/mysql.conf

ersetzen Sie character_set_server=utf8, um utf8mb4 zu werden. Kommentieren Sie collation_server= gemäß diesem Dokument aus. Die Standardeinstellung ist gut https://dev.mysql.com/doc/refman/8.0/en/charset- server.html

Ich glaube nicht, dass wir etwas gegen secure_file_priv= Tun können. Ich glaube, akonadi braucht es leer, um Dateien von beliebigen Orten laden zu können. doc: https://dev.mysql.com/doc/refman/8.0/en/string-functions.html

dann der eigentliche Fehler Failed to find valid data directory

da es sich bei akonadi hauptsächlich um temporäre Daten handelt, ist es meiner Meinung nach am einfachsten, das Verzeichnis db_data zu beenden und von vorne zu beginnen. Wir werden den Ordner umbenennen, anstatt ihn zu löschen

$ 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

die Option --initialize startet das Verzeichnis db_data frisch. Wenn Sie beide Verzeichnisse vergleichen, sehen Sie eine Reihe von Dateien, die sich von der vorherigen unterscheiden.

jetzt wird dieser Fehler angezeigt

[ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0').

Ich schalte diese Option lower_case_table_names= In mysql.conf von 1 auf 0 um

sie müssen diese veraltete Option auch auskommentieren

log_warnings=2

Ich rufe mysqld-akonadi nicht mehr direkt mit den langen Argumenten auf, sondern führe einfach akonadiserver und cat in der Protokolldatei mysql.error aus

diesen Fehler jetzt bekommen [Server] unknown variable 'query_cache_size=0'

werde dies kommentieren

müssen auch auskommentieren query_cache_type=0

und akonadi kann mit MySQL 8 ausgeführt werden

Zusammenfassend:

  • utf8 bis utf8mb4 ist eine gute Änderung, beide auskommentiert zu lassen, ist die neue Standardeinstellung
  • kommentieren Sie die 4 veralteten Optionen aus
  • verschieben Sie Ihr altes db_data-Verzeichnis und erstellen Sie stattdessen ein leeres Verzeichnis
  • starten Sie akonadiserver neu

Hoffe das hilft

Update: Wenn Sie diesen Fehler erhalten

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"

dies bedeutet, dass die Spalte bereits hinzugefügt wurde, die Datenbankmigration jedoch nicht als abgeschlossen markiert wurde. Ich würde empfehlen, den Ordner db_data Erneut zu beenden und die Initialisierung manuell auszuführen. und akonadiserver starten

es läuft endlich für mich. und korganizer, der am 19.04 ständig abstürzte, läuft jetzt;)

Update (2020): Seien Sie sehr vorsichtig mit diesem Fehler, wenn Sie Ihre Akonadi-Datenbank zurücksetzen https://bugs.kde.org/show_bug.cgi?id=4144

Seit 19.10 hatte ich zu viele Probleme. Weder MariaDB noch MySQL 8 haben gut funktioniert. Ich musste Akonadi zurücksetzen. Schließlich lief MySQL 5.6 und 5.7 über 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

aber immer wieder Probleme. Ich habe Akonadi/kdepim aufgegeben, alle zugehörigen Pakete deinstalliert und zu Thunderbird gewechselt. Plasma läuft reibungslos.

2
Mathieu J.

Ich hatte auch Akonadi-Probleme seit dem Update von Kubuntu 19.04 auf 19.10. Die MySQL-Protokolldatei ~/.local/share/akonadi/db_data/mysql.err Enthielt Fehler wie:

unknown variable 'log-warnings=2'

Also habe ich diese in /home/NNN/.local/share/akonadi/mysql.conf Auskommentiert:

# 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

Um ehrlich zu sein, war es mir egal, welche Variablen geändert wurden und welche Konsequenzen dies haben würde ...

1
user1008792

Der Fehler besagt, dass es in MySQL eine Benutzertabelle mit dem Namen index_stats Gibt, was seltsam erscheint. Es sei denn, Sie oder eines der von Ihnen verwendeten Programme haben diese Tabelle erstellt.

Mit anderen Worten, Sie können keine Tabellen mit diesem Namen mehr haben, da MySQL 8.0 eine Tabelle mit diesem Namen verwendet.

Sie können versuchen, die Datei in index_stats_bak.frm Umbenennen, aber es ist schwer zu sagen, was mit dem Programm passiert, das das verwendet.

Dieser Beitrag enthält eine Liste von Tabellennamen, die jetzt vom System verwendet werden, darunter index_stats.

Wenn man sich die Quelle für Akonadi ansieht, die Tabellen erstellt, scheint es sehr unwahrscheinlich, dass es einen Konflikt mit MySQL 8 gibt. Ich vermute, dass es ein teilweises Upgrade von MySQL gab, das den Teil der neuen Tabellen aber verlassen hat nicht alle. index_stats wurde wahrscheinlich in diesem Teilupdate erstellt.

0
Victory