kalarm ne démarre plus
le service de gestion des informations personnelles n'est pas opérationnel
Environnements Graphiques / KDE Plasma
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Au lancement de kalarm, une fenêtre m'indique que "le service de gestion des informations personnelles n'est pas opérationnel" et kalarm ne démarre pas.
Même résultat avec kmail.
La fenêtre propose bien un bouton Détails mais il n'a aucun effet.
Quand je lance kalarm dans konsole, j'obtiens ça :
Code BASH :
$ kalarm Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.pim.akonadiserver: Starting up the Akonadi Server... Attribute Qt::AA_EnableHighDpiScaling must be set before QCoreApplication is created. QDBusConnection: name 'org.kde.JobViewServer' had owner '' but we thought it was ':1.24' Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) QSystemTrayIcon::setVisible: No Icon set org.kde.pim.akonadiserver: database server stopped unexpectedly org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection! org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld" org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/user1/.local/share/akonadi/mysql.conf", "--datadir=/home/user1/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-user1.N8bq0n/mysql.socket", "--pid-file=/tmp/akonadi-user1.N8bq0n/mysql.pid") org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "2020-12-25 22:20:55 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB) starting as process 21387 ...\n" org.kde.pim.akonadiserver: exit code: 1 org.kde.pim.akonadiserver: process error: "Unknown error" /usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/tmp/akonadi-user1.N8bq0n/mysql.socket' (2)' Check that mysqld is running and that the socket: '/tmp/akonadi-user1.N8bq0n/mysql.socket' exists! org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadiserver: Shutting down AkonadiServer... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally... org.kde.pim.akonadicore: Job error: "" for collection: QVector() org.kde.pim.akonadicore: Job error: "" for collection: QVector() org.kde.pim.akonadicore: Job error: "" for collection: QVector()
C'est un sacré problème puisque la DB mysql stocke les alarmes, les agendas et les mails.
Alors aujourd'hui, je n'ai plus rien d'accessible !
Quelqu'un aurait-il une rustine ?
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Il faut voir pourquoi le serveur sql ne démarre pas.
Si tu as le temps :
https://www.mageialinux-online.org/forum/topic-28081+akonadi-kalarm-lubuntu-20-04.php
Que donne
Code :
/sbin/mysqld --version
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Code BASH :
akonadictl start --verbose cat /home/${USER}/.local/share/akonadi/db_data/mysql.err
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Code BASH :
cat /home/${USER}/.local/share/akonadi/mysql.conf
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Citation :
J'ai pas tout lu mais ça semble plutôt tourner autour du mysql.conf alors que dans mon cas, ça serait plutôt le ibdata1 qu'est pas vraiment comme il devrait être.
Résultat des commandes :
Caché :
Code BASH :
$ /sbin/mysqld --version /sbin/mysqld Ver 10.3.27-MariaDB for Linux on x86_64 (Mageia MariaDB Server) $ akonadictl start --verbose Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) [zwykx@localhost src]$ org.kde.pim.akonadiserver: Starting up the Akonadi Server... org.kde.pim.akonadiserver: Found mysql_install_db: "/usr/bin/mysql_install_db" org.kde.pim.akonadiserver: Found mysqlcheck: "/usr/bin/mysqlcheck" org.kde.pim.akonadiserver: Using mysqld: "/usr/sbin/mysqld" org.kde.pim.akonadiserver: mysqld reports version 10.3.27 (MariaDB) org.kde.pim.akonadiserver: Executing: "/usr/sbin/mysqld" "--defaults-file=/home/zwykx/.local/share/akonadi/mysql.conf --datadir=/home/zwykx/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-zwykx.mVbCt2/mysql.socket --pid-file=/tmp/akonadi-zwykx.mVbCt2/mysql.pid" org.kde.pim.akonadiserver: database server stopped unexpectedly org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection! org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld" org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/zwykx/.local/share/akonadi/mysql.conf", "--datadir=/home/zwykx/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-zwykx.mVbCt2/mysql.socket", "--pid-file=/tmp/akonadi-zwykx.mVbCt2/mysql.pid") org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "2020-12-26 9:55:13 0 [Note] /usr/sbin/mysqld (mysqld 10.3.27-MariaDB) starting as process 15325 ...\n" org.kde.pim.akonadiserver: exit code: 1 org.kde.pim.akonadiserver: process error: "Unknown error" org.kde.pim.akonadiserver: terminating connection threads org.kde.pim.akonadiserver: terminating service threads org.kde.pim.akonadiserver: stopping db process /usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/tmp/akonadi-zwykx.mVbCt2/mysql.socket' (2)' Check that mysqld is running and that the socket: '/tmp/akonadi-zwykx.mVbCt2/mysql.socket' exists! org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadiserver: Shutting down AkonadiServer... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally... ' $ ll /tmp/akonadi-zwykx.mVbCt2/ total 0 $ cat /home/zwykx/.local/share/akonadi/db_data/mysql.err 2020-12-26 9:55:13 0 [Note] InnoDB: Using Linux native AIO 2020-12-26 9:55:13 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2020-12-26 9:55:13 0 [Note] InnoDB: Uses event mutexes 2020-12-26 9:55:13 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2020-12-26 9:55:13 0 [Note] InnoDB: Number of pools: 1 2020-12-26 9:55:13 0 [Note] InnoDB: Using generic crc32 instructions 2020-12-26 9:55:13 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2020-12-26 9:55:13 0 [Note] InnoDB: Completed initialization of buffer pool 2020-12-26 9:55:13 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2020-12-26 9:55:13 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 2020-12-26 9:55:13 0 [ERROR] InnoDB: Corrupted page [page id: space=0, page number=0] of datafile './ibdata1' could not be found in the doublewrite buffer. 2020-12-26 9:55:13 0 [ERROR] InnoDB: Plugin initialization aborted with error Data structure corruption 2020-12-26 9:55:14 0 [Note] InnoDB: Starting shutdown... 2020-12-26 9:55:14 0 [ERROR] Plugin 'InnoDB' init function returned error. 2020-12-26 9:55:14 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2020-12-26 9:55:14 0 [ERROR] Unknown/unsupported storage engine: innodb 2020-12-26 9:55:14 0 [ERROR] Aborting $ ll /home/zwykx/.local/share/akonadi/db_data/ibdata1 -rw------- 1 zwykx zwykx 76M déc. 19 15:22 /home/zwykx/.local/share/akonadi/db_data/ibdata1 $ hexdump /home/zwykx/.local/share/akonadi/db_data/ibdata1 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 4c00000 $ cat /home/zwykx/.local/share/akonadi/mysql.conf # # Global Akonadi MySQL server settings, # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris@mysql.com> # [mysqld] # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled # sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat # sql_mode=strict_trans_tables # DEBUGGING: # log all queries, useful for debugging but generates an enormous amount of data # log=mysql.full # log queries slower than n seconds, log file name relative to datadir (for debugging only) # log_slow_queries=mysql.slow # long_query_time=1 # log queries not using indices, debug only, disable for production use # log_queries_not_using_indexes=1 # # mesure database size and adjust innodb_buffer_pool_size # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); # NOTES: # Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) #expire_logs_days=3 #sync_bin_log=0 # Use UTF-8 encoding for tables character_set_server=utf8 collation_server=utf8_general_ci # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # memory pool InnoDB uses to store data dictionary information and other internal data structures (default:8M) # Deprecated in MySQL >= 5.6.3, removed in 5.7 (works in MariaDB) # innodb_additional_mem_pool_size=8M # memory buffer InnoDB uses to cache data and indexes of its tables (default:128M) # Larger values means less I/O innodb_buffer_pool_size=128M # Create a .ibd file for each table (default:0) innodb_file_per_table=1 # Write out the log buffer to the log file at each commit (default:1) innodb_flush_log_at_trx_commit=2 # Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin) # larger values means less I/O innodb_log_buffer_size=1M # Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery. innodb_log_file_size=64M # # error log file name, relative to datadir (default:hostname.err) log_error=mysql.err # print warnings and connection errors (default:1) log_warnings=2 # Convert table named to lowercase lower_case_table_names=1 # Maximum size of one packet or any generated/intermediate string. (default:1M) max_allowed_packet=32M # Maximum simultaneous connections allowed (default:100) max_connections=256 # The two options below make no sense with prepared statements and/or transactions # (make sense when having the same query multiple times) # Memory allocated for caching query results (default:0 (disabled)) query_cache_size=0 # Do not cache results (default:1) query_cache_type=0 # Do not use the privileges mechanisms skip_grant_tables # Do not listen for TCP/IP connections at all skip_networking # The number of open tables for all threads. (default:64) table_open_cache=200 # How many threads the server should cache for reuse (default:0) thread_cache_size=3 # wait 365d before dropping the DB connection (default:8h) wait_timeout=31536000 # We use InnoDB, so don't let MyISAM eat up memory key_buffer_size=16K [client] default-character-set=utf8
Ca me parait assez inquiétant parceque si il contient vraiment 76 M de données utiles, ça va pas etre facile de le re-générer correctement.
Qu'en pense l'expert de service ?
Édité par zwykx Le 26/12/2020 à 11h53
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
Je n' ai toujours pas compris ce qui est contenu dans la base d' Akonadi...
Est ce que cela contient effectivement les données ou est ce "uniquement" qu' un cache pour des interactions inter applications ?
Parce que dans le deuxième cas, renommer le /home/${USER}/.local/share/akonadi/ devrait être suffisant , afin de recréer une base vierge qui serait re remplie après réouverture des applications.
Sinon, on peut peut être démarrer rajoutant l' option innodb_force_recovery=1 au fichier de configuration home/zwykx/.local/share/akonadi/mysql.conf, ce qui devrait peut être permettre de faire un dump de la base (mais reste la question du ré import des données).
https://dba.stackexchange.com/questions/45991/mysql-ibdata1-corrupt
https://mariadb.com/kb/en/innodb-recovery-modes/
Dans un premier temps (et ce dans les deux cas de figure), il faudrait copier ailleurs le répertoire /home/${USER}/.local/share/akonadi/ afin d' avoir une sauvegarde de l' existant.
Puis renommer le home/${USER}/.local/share/akonadi/ sous un autre nom et essayer de redémarrer akonadi (dans le cas de Bisane, kalarm semble stocker ses données ailleurs que dans la base)
edit: visiblement, on ne devrait pas perdre grand chose a renommer le répertoire de base. https://blogs.kde.org/node/4503
Édité par nic80 Le 26/12/2020 à 18h19
steven Membre non connecté
-
- Voir le profil du membre steven
- Inscrit le : 18/05/2018
No Comment ... 
Merci de ne pas 'rebondir' sur mes post's Censor => 2025
Merci de ne pas 'rebondir' sur mes post's Censor => 2025
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
steven :
Le temps que tu passe a me critiquer... moi je le passe a évoluer ! Question de priorité.
Euuuh, j'ai l'impression que je tombe en plein règlement de comptes :-S
Alors j'ai d'abord essayé la technique :
nic80 :
mais ça a pas marché. Mes alarmes avaient toutes disparues.renommer le /home/${USER}/.local/share/akonadi/
Et comme indiqué dans :
https://dba.stackexchange.com/questions/45991/mysql-ibdata1-corrupt
Citation :
You should not kill MySQL it is not a good practice that may cause MySQL server to crash,whenever you make any configuration changes you should proceed as follows.
Or ce qui m'est arrivé c'est tout bêtement un redémarrage brutal suite à un freeze de l'interface graphique.
Finalement, j'ai constaté que malgré les opérations de maintenance en cours sur cette config, la sauvegarde journalière avait fonctionné. Donc j'ai restauré /home/zwykx/.local/share/akonadi* ce qui m'a permis de tout récupérer mais dans un drôle d'état ...
... En redémarrant, toutes mes alarmes sont dupliquées donc c'est un peu la pagaille.
Mais surtout, je me récupère des messages d'erreur qui polluent mes log toutes le secondes :
Code BASH :
# journalctl -e ... janv. 06 22:00:29 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:29 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:29 localhost.localdomain akonadi_kalarm_resource[23965]: 211 -> QFlags(0x2) 0 janv. 06 22:00:29 localhost.localdomain akonadi_kalarm_resource[23965]: janv. 06 22:00:30 localhost.localdomain akonadi_kalarm_resource[23969]: The hash has changed. janv. 06 22:00:30 localhost.localdomain akonadi_kalarm_resource[23969]: The hash has changed. janv. 06 22:00:31 localhost.localdomain akonadi_kalarm_resource[23969]: 213 -> QFlags(0x2) 0 janv. 06 22:00:31 localhost.localdomain akonadi_kalarm_resource[23969]: janv. 06 22:00:32 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:32 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:32 localhost.localdomain akonadi_kalarm_resource[23965]: 211 -> QFlags(0x2) 0 janv. 06 22:00:32 localhost.localdomain akonadi_kalarm_resource[23965]: janv. 06 22:00:34 localhost.localdomain akonadi_kalarm_resource[23969]: The hash has changed. janv. 06 22:00:34 localhost.localdomain akonadi_kalarm_resource[23969]: The hash has changed. janv. 06 22:00:34 localhost.localdomain akonadi_kalarm_resource[23969]: 213 -> QFlags(0x2) 0 janv. 06 22:00:34 localhost.localdomain akonadi_kalarm_resource[23969]: janv. 06 22:00:35 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:35 localhost.localdomain akonadi_kalarm_resource[23965]: The hash has changed. janv. 06 22:00:35 localhost.localdomain akonadi_kalarm_resource[23965]: 211 -> QFlags(0x2) 0 janv. 06 22:00:35 localhost.localdomain akonadi_kalarm_resource[23965]:
J'ai essayé de restaurer tout /home/zwykx/.local mais ça n'a rien changé.
J'ai donc tenté de restaurer /home/zwykx/{.cache,.config,.kde,.local} -> même résultat !
Sauf que à chaque restauration, les alarmes sont dupliquées donc je suis passé de 50 alarmes à 100 puis 150 alors que je supprimais à chaque fois les anciens fichiers .cache,.config,.kde,.local.
Il doit donc y avoir encore un autre fichier qui gère les alarmes quelque part, mais où !
Je reviens sur la cause du problème.
J'ai l'impression que les développeurs ont pris un gros risque avec cette architecture akonadi.
A moins d'équiper son matériel d'un onduleur, personne n'est à l'abri d'une coupure de courant et encore moins d'un crash avec redémarrage par le bouton marche/arrêt.
Alors si quelqu'un a une idée de la cause des messages plus haut, je suis preneur.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Normalement, ça devrait les rajouter. Si ça ne les rajoute pas, on pourra regarder plus loin.
PS : Bon j'ai apparemment dit des bêtises, car seul akonadi a été renommé, et on perd kalarm... Alors que celui ci serait dans :
/home/${USER}/.local/share/kalarm/calendar.ics
Si tu peux "rien avoir" pour repartir d'un truc vierge, puis restaurer une seule fois kalarm, ça serait l'idéal non ?
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
Cela ne va peut-être pas trop t'aider pour l'instant mais, si cela ne veut vraiment pas le faire, tu peux peut-être tout migrer sous Thunderbird avec les bons modules complémentaires.
J'ai fini par faire cela suite à un service akonadi trop capricieux que je n'ai jamais réussi à redémarrer suite à une mise à jour de KDE frameworks et MySQL ; justement, pour un problème avec MySQL...
A+
OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
J'ai rencontré le même problème que toi sur mon installation toute neuve de la beta 2. Impossible de démarrer Knote ou Korganizer
J'ai trouvé sur le bugzilla un moyen de contournement pour réinitialiser la configuration de Akonadi, et depuis, ça fonctionne bien.
Code TEXT :
As a workaround, the 'export -> nuke akonadi -> reimport' route works fine. The workaround steps are: 1. Open KOrganizer, 'File->Export->Export as iCalendar', and save the file. 2. Open KAddressBook, 'File->Export->Export vCard 4.0...', and save the file. 3. For KMail, KAlarm, and KJots, I did nothing as these were unused. I'm not sure what you would do for these. 4. Log into a virtual terminal with no X, e.g. run 'init 3' as root. 5. Nuke Akonadi: $ rm -rf ~/.cache/akonadi* $ mv ~/.config/akonadi ~/.config/akonadi_old $ mv ~/.local/share/akonadi ~/.local/share/akonadi_old 6. Restart X, e.g. 'init 5' as root. 7. Log into the plasma desktop and let akonadi reconfigure itself. 8. Open KOrganizer, 'File->Import->Import Calendar', and select the saved file. 9. Open KAddressBook, 'File->Import->Import vCard...', and select the saved file. Now KOrganizer and KAddressBook are functional again
Espérons que ça puisse te dépanner aussi.
@+
Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
OPS56 :
J'ai trouvé sur le bugzilla un moyen de contournement pour réinitialiser la configuration de Akonadi,
Bonjour,
Peux-tu citer le rapport ?
OPS56 Membre non connecté
-
- Voir le profil du membre OPS56
- Inscrit le : 18/11/2008
- Groupes :
Papoteur :
Bonjour,
Peux-tu citer le rapport ?
OPS56 :
J'ai trouvé sur le bugzilla un moyen de contournement pour réinitialiser la configuration de Akonadi,
Bonjour,
Peux-tu citer le rapport ?
Bonjour Papoteur,
Oui, c'est le 26096
@+
Dell G3-15 Intel Corei7 - 16Go Ram - Nvidia GTX1660 Ti (Tri boot Mageia 9- 64 bits / Linux Mint 20 Cinamon/ Windows 10)
Core i5 760 - 8Go Ram - Nvidia Gforce 450 - (Triple boot Mageia 9-64 bits - Plasma 5 / Mint 20 Cinamon / Open Suse Tumbleweed - Plasma 5)
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
J'ai du réparer entre temps (avec des sauvegardes un peu dispersées) mon disque cramé sur le seul ordi connecté à internet. Aaaah les sauvegardes 8D
jybz :
Alors que celui ci serait dans :
/home/${USER}/.local/share/kalarm/calendar.ics
/home/${USER}/.local/share/kalarm/calendar.ics
En effet, tout est encore dans /home/${USER}/.local/share/kalarm/, même les alarmes expirées.
Alors à quoi servent les 76 M de /home/zwykx/.local/share/akonadi/db_data/ibdata1 ?
squid-f :
tu peux peut-être tout migrer sous Thunderbird
j'ai déjà essayé. L'architecture est nettement plus saine. Mais l'intégration avec plasma n'est pas terrible, le simple clic est pas supporté et je supporte pas l'interface en onglets, etc.
J'ai finalement essayé la méthode OPS56.
J'ai :
- ouvert kalarm
- tout sélectionné
- exporté les alarmes dans un fichier .ics
- fermé ma session
- logué dans un tty (Ctrl+Alt+F2)
- tué les process zwykx encore vivants (il y en a quand même + d'une vingtaine ; on se demande à quoi ça sert de fermer une session)
puis :
$ rm -rf ~/.cache/akonadi*
$ mv ~/.config/akonadi ~/.config/akonadi.old
$ mkdir ~/.config/akonadi_kalarm_ressource.old
$ mv ~/.config/akonadi_kalarm_ressource* ~/.config/akonadi_kalarm_ressource.old
$ mv ~/.local/share/akonadi ~/.local/share/akonadi.old
$ mkdir ~/.local/share/akonadi_kalarm_ressource.old~/.local/share/akonadi_kalarm_ressource.old
$ mv ~/.local/share/akonadi_kalarm_ressource* ~/.local/share/akonadi_kalarm_ressource.old
- réouvert ma session
Et là, sans restaurer quoi que ce soit, mes alarmes se sont affichées toutes seules et j'ai même récupéré de vieilles alarmes que j'avais perdues.
Par contre, kmail est vide maintenant, j'ai perdu des années de messagerie.
Ya pas à dire akonadi est une réussite.
zwykx Membre non connecté
-
- Voir le profil du membre zwykx
- Inscrit le : 21/01/2013
- Groupes :
Les alarmes sont revenues à leur été initial mais kmail est vide. Plus de messages !
Pourtant quand je regarde la configuration, tous mes comptes de messagerie sont là, en imap et en pop, et tous les process akonadi de relevage de courrier sont présents :
Code BASH :
$ ps -ef | grep akonadi zwykx 12145 1 0 14:01 ? 00:00:03 /usr/bin/akonadi_control zwykx 12152 12145 3 14:01 ? 00:00:40 /usr/bin/akonadiserver zwykx 12161 12152 6 14:01 ? 00:01:07 /usr/sbin/mysqld --defaults-file=/home/zwykx/.local/share/akonadi/mysql.conf --datadir=/home/zwykx/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-zwykx.TThPKz/mysql.socket --pid-file=/tmp/akonadi-zwykx.TThPKz/mysql.pid zwykx 12250 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_0 zwykx 12251 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent zwykx 12252 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_birthdays_resource --identifier akonadi_birthdays_resource zwykx 12253 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0 zwykx 12254 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_followupreminder_agent --identifier akonadi_followupreminder_agent zwykx 12255 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_0 zwykx 12256 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_0 zwykx 12257 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_1 zwykx 12258 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_10 zwykx 12259 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_11 zwykx 12260 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_12 zwykx 12261 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_2 zwykx 12262 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_3 zwykx 12263 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_5 zwykx 12264 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_7 zwykx 12266 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_8 zwykx 12267 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_9 zwykx 12268 12145 1 14:01 ? 00:00:17 /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent zwykx 12269 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_kalarm_resource --identifier akonadi_kalarm_resource_0 zwykx 12270 12145 32 14:01 ? 00:05:47 /usr/bin/akonadi_kalarm_resource --identifier akonadi_kalarm_resource_1 zwykx 12271 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_kalarm_resource --identifier akonadi_kalarm_resource_2 zwykx 12272 12145 32 14:01 ? 00:05:52 /usr/bin/akonadi_kalarm_resource --identifier akonadi_kalarm_resource_7 zwykx 12273 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_kalarm_resource --identifier akonadi_kalarm_resource_8 zwykx 12274 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0 zwykx 12277 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent zwykx 12278 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent zwykx 12279 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent zwykx 12281 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent zwykx 12282 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_notes_agent --identifier akonadi_notes_agent zwykx 12284 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_0 zwykx 12285 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_1 zwykx 12287 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_2 zwykx 12288 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_3 zwykx 12289 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_4 zwykx 12290 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_5 zwykx 12291 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_6 zwykx 12292 12145 0 14:01 ? 00:00:00 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_7 zwykx 12293 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_sendlater_agent --identifier akonadi_sendlater_agent zwykx 12294 12145 0 14:01 ? 00:00:01 /usr/bin/akonadi_unifiedmailbox_agent --identifier akonadi_unifiedmailbox_agent zwykx 13671 13112 0 14:19 pts/1 00:00:00 grep --color akonadi
Toujours aussi fort akonadi.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie