Created attachment 106544 [details] kmail-related-packages-installed.txt Hello, I use opensuse leap 42.2 with kde , kmail2, plasma5, kontact, akonadi, mariadb . uname -a Linux <hostname>.dom 4.4.74-18.20-default #1 SMP Fri Jun 30 19:01:19 UTC 2017 (b5079b8) x86_64 x86_64 x86_64 GNU/Linux The levels of kmail, akonadi... packages are provided in one of the attachments. For several week I noticed that some emails are received again even if they are deleted/moved to trash and the settings of account is set to not keeping emails longer than 7 days . In the last 2 weeks the issue has become more annoying . Yesterday I applied the latest maintenance available via zypper up and it touched the kmail, akonadi packages . After rebooting the machine I start receiving hundreds of emails with date back to 10-June-2017 . I thought that id they are moved to trash that will stop . I was mistaken ... they appeared again and again regardless if the emails were moved to trash or simply deleted . To alleviate this aggravation I created a filter to direct all emails with date before July 7 2017 into a new folder <Check-the-News> . All other filters which started receiving some where from 10 to 80/90 emails were changed to direct the emails in the above described folder . akonadictl fsck and/or vacuum has no effect on this issue . I noticed hundreds of lines " Item ...... has no RID " . akonadictl listings are provided below because I was able to attach only one attachment . Questions : 1. Is there any way to check the mysql [ i.e. maridb ] database used by kmail2 ? If there is , could you please give me some info/procedures ? 2). How could I get rid of all those "Item ..... has no RID." ? Is it possible ? 3). It seems that potentially the existing database id toasted . What would be the procedure for a) full backup of the existing kmail2/akonadi environment b) total removal of the existing kmail2/akonadi environment c) creating a brand new kmail2/akonadi env d) migrating the emails from the backup (a) to the new env . I hope that there are some "kmail/akonadi/mariadb" solutions . Thank you, Nick Dordea ------------------------------------- akonadictl_status_fsck_vacuum_restart.txt <user@hostname>:~> akonadictl status Akonadi Control: running Akonadi Server: running Akonadi Server Search Support: available (Remote Search) Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_vcard_resource, akonadi_vcarddir_resource You have new mail in /var/spool/mail/<user> <user@hostname>:~> akonadictl fsck Looking for resources in the DB not matching a configured resource... Looking for collections not belonging to a valid resource... Checking collection tree consistency... Looking for items not belonging to a valid collection... Looking for item parts not belonging to a valid item... Looking for item flags not belonging to a valid item... Looking for overlapping external parts... Verifying external parts... Found 1554 external files. Cleaning up missing external file: /home/<user>/.local/share/akonadi/file_db_data/85/311685_r0 for item: 79413 on part: 311685 Found 1550 external parts. Found unreferenced external file: /home/<user>/.local/share/akonadi/file_db_data/06/313706_r1 Found unreferenced external file: /home/<user>/.local/share/akonadi/file_db_data/35/314735_r3 Found unreferenced external file: /home/<user>/.local/share/akonadi/file_db_data/85/311685_r1 Found unreferenced external file: /home/<user>/.local/share/akonadi/file_db_data/23/330323_r1 Moved 4 unreferenced files to lost+found. Checking size treshold changes... Found 0 parts to be moved to external files Found 0 parts to be moved to database Looking for dirty objects... Collection "Search" (id: 1) has no RID. Collection "OpenInvitations" (id: 459) has no RID. Collection "DeclinedInvitations" (id: 460) has no RID. Found 3 collections without RID. Item "47136" has no RID. Item "47138" has no RID. Item "49811" has no RID. Item "49812" has no RID. Item "49813" has no RID. ...... Item "84589" has no RID. Item "84590" has no RID. Item "84591" has no RID. Found 342 items without RID. Found 0 dirty items. Looking for rid-duplicates not matching the content mime-type of the parent collection Checking Active Alarms Checking Alarm Templates Checking Archived Alarms Checking Birthdays & Anniversaries Checking Local Folders Checking Notes Checking Personal Contacts Checking Search Checking akonadi_ical_resource_0 Checking DeclinedInvitations Checking OpenInvitations Checking ufyPf9BvAo Checking Alarm_Templates Checking Check-if-Spam Checking Check-if-Virus Checking Check_the_News Found duplicates 1499712179.R37.<hostname.dom> <---- lots of them due to receiving the same email multiple times <user@hostname>:~> find $HOME/.local -type f -name "*1499712179*R37*" /home/<user>/.local/share/akonadi_maildir_resource_0/Check_the_News/cur/1499712179.R37.<hostname>.dom All emails having date before 07-July-2017 are moved in Check_the_News folder . Checking drafts Checking inbox Checking outbox Checking sent-mail Checking templates Checking trash ....... Checking <user's folders> ....... Migrating parts to new cache hierarchy... Consistency check done. <user@hostname>:~> akonadictl vacuum vacuuming database, that'll take some time and require a lot of temporary disk space... optimizing table SchemaVersionTable... optimizing table ResourceTable... optimizing table CollectionTable... optimizing table MimeTypeTable... optimizing table PimItemTable... optimizing table FlagTable... optimizing table PartTypeTable... optimizing table PartTable... optimizing table CollectionAttributeTable... optimizing table TagTypeTable... optimizing table TagTable... optimizing table TagAttributeTable... optimizing table TagRemoteIdResourceRelationTable... optimizing table RelationTypeTable... optimizing table RelationTable... optimizing table PimItemFlagRelation... optimizing table PimItemTagRelation... optimizing table CollectionMimeTypeRelation... optimizing table CollectionPimItemRelation... vacuum done <user@hostname>:~> akonadictl restart Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) <user@hostname>:~> 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 Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.akonadi.ETM: GEN true false false org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: org.kde.akonadi.ETM: Subtree: 594 QSet(663, 662, 661, 660, 659, 658, 657, 656, 655, 654, 653, 652, 651, 650, 649, 648, 647, 646, 645, 644, 643, 642, 641, 640, 639, 638, 637, 636, 635, 634, 633, 632, 631, 630, 629, 628, 627, 626, 625, 624, 623, 622, 621, 620, 619, 618, 617, 616, 615, 738, 613, 737, 612, 611, 610, 609, 733, 608, 607, 731, 606, 730, 605, 729, 604, 728, 603, 727, 602, 726, 601, 725, 600, 724, 599, 723, 722, 597, 596, 595, 594, 717, 716, 714, 713, 708, 700, 698, 697, 696, 695, 693, 692, 691, 690, 689, 688, 687, 686, 685, 683, 681, 679, 678, 677, 675, 674, 673, 672, 671, 670, 669, 668, 667, 666) org.kde.akonadi.ETM: Fetch job took 49 msec org.kde.akonadi.ETM: was collection fetch job: collections: 115 org.kde.akonadi.ETM: first fetched collection: "Local Folders" org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: Fetch job took 56 msec org.kde.akonadi.ETM: was collection fetch job: collections: 9 org.kde.akonadi.ETM: first fetched collection: "Search" org.kde.akonadi.ETM: Fetch job took 2 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0 org.kde.akonadi.ETM: GEN true false false org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: org.kde.akonadi.ETM: Subtree: 594 QSet(604, 605, 606, 607, 733, 600, 601, 602, 603, 728, 596, 729, 597, 730, 731, 599, 724, 725, 726, 594, 727, 595, 722, 723, 685, 686, 687, 681, 683, 677, 678, 679, 672, 673, 674, 675, 700, 696, 697, 698, 692, 693, 695, 688, 689, 690, 691, 652, 653, 654, 655, 648, 649, 650, 651, 644, 645, 646, 647, 640, 641, 642, 643, 668, 669, 670, 671, 666, 667, 660, 661, 662, 663, 656, 657, 658, 659, 620, 621, 622, 623, 616, 617, 618, 619, 612, 613, 615, 608, 609, 610, 611, 737, 636, 738, 637, 638, 639, 632, 633, 634, 635, 628, 629, 630, 631, 624, 625, 626, 627, 716, 717, 713, 714, 708) org.kde.akonadi.ETM: Fetch job took 114 msec org.kde.akonadi.ETM: was collection fetch job: collections: 115 org.kde.akonadi.ETM: first fetched collection: "Local Folders" org.kde.akonadi.ETM: collection: QVector() org.kde.akonadi.ETM: Fetch job took 144 msec org.kde.akonadi.ETM: was collection fetch job: collections: 9 org.kde.akonadi.ETM: first fetched collection: "Search" org.kde.akonadi.ETM: Fetch job took 3 msec org.kde.akonadi.ETM: was collection fetch job: collections: 0 <user@hostname>:~>
Created attachment 106546 [details] akonadictl_status_fsck_vacuum_restart.txt
Created attachment 106561 [details] BugID-383216_A view at the email types I have to deal with.txt Counts of the amount of old emails I receive , mostly of them older than one week the majority if them from June 2017 .
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Bug Janitor Service from comment #4) > Dear Bug Submitter, > > This bug has been in NEEDSINFO status with no change for at least > 15 days. Please provide the requested information as soon as > possible and set the bug status as REPORTED. Due to regular bug > tracker maintenance, if the bug is still in NEEDSINFO status with > no change in 30 days the bug will be closed as RESOLVED > WORKSFORME > due to lack of needed information. > > For more information about our bug triaging procedures please read the > wiki located here: > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging > > If you have already provided the requested information, please > mark the bug as REPORTED so that the KDE team knows that the bug is > ready to be confirmed. > > Thank you for helping us make KDE software even better for everyone! Hello, It is a while since these events happened . Since then my machine as well as KDE/Kmail2 were upgraded . Now I use opensuse leap 15.4 and kmail /kontact is at level 5.19.3(21.12.3 ) With very few exceptions [ response time ] I haven't noticed the symptoms reported in 2017 . So I cannot recreate the 2017 failures . I still have problems with akonadictl fsck message regarding records with no RID. It is possible to have akonadictl fsck repair .... option that will [re]move the affected emails to another directory ... i.e. TB_handled_by_the_user ? The we can decide about them ..... If this comment helps, as far as I am concerned this bug can be closed . Thank you for your support . Best regards, Nick
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!