[kmail2] [Bug 382216] New: Lots of old emails [ days, weeks ] are received over and over again even if they are deleted/moved to trash

Nick bugzilla_noreply at kde.org
Mon Jul 10 21:14:26 BST 2017


https://bugs.kde.org/show_bug.cgi?id=382216

            Bug ID: 382216
           Summary: Lots of old emails [ days, weeks ] are received over
                    and over again even if they are deleted/moved to trash
           Product: kmail2
           Version: 5.5.2
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: commands and actions
          Assignee: kdepim-bugs at kde.org
          Reporter: ndordea at gmail.com
  Target Milestone: ---

Created attachment 106544
  --> https://bugs.kde.org/attachment.cgi?id=106544&action=edit
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 at 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 at 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 at 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 at 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 at hostname>:~> akonadictl restart
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
<user at 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 at hostname>:~>

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Kdepim-bugs mailing list