Bug 422490

Summary: maildir resource gets stuck on synchronizing a folder with 72 messages
Product: [Frameworks and Libraries] Akonadi Reporter: Martin Steigerwald <Martin>
Component: Maildir ResourceAssignee: kdepim bugs <kdepim-bugs>
Status: CONFIRMED ---    
Severity: normal CC: phil-deb1.merlin, rasasi78
Priority: NOR    
Version: 5.14.1   
Target Milestone: ---   
Platform: Debian unstable   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: KMail reporting maildir synchronizing trash folder

Description Martin Steigerwald 2020-06-05 15:44:19 UTC
Created attachment 129077 [details]
KMail reporting maildir synchronizing trash folder

This is with KDEPIM/Akonadi 20.04 on Debian Sid, using PostgreSQL 12. I don't think I saw this with KDEPIM/Akonadi 19.08.

SUMMARY

Synchronizing a maildir folder even with just a few thousand messages or in this case with about a hundred messages can get stuck. During this time Akonadi does not react to any request of KMail to get the payload of a mail I click on. Which basically makes KMail mostly unusable as it won't display any mails Akonadi did not retrieve the payload for shortly ago.

Often akonadi_maildir_resource consumes about 100% of one core (Intel Sandybridge i5) for a minute or longer. In case it gets stuck, CPU usage drops. This is about the case where it gets stuck.


STEPS TO REPRODUCE
1. Use KMail and Akonadi with some POP3 mail accounts delivering. 
2. Retrieve new mails or even just switch to a folder not synchronized recently.

OBSERVED RESULT

akonadi_maildir_resource takes much, much longer than with Akonadi 19.08 or even gets stuck. In the case for this report it gets stuck.

Here is an strace and it just seems to poll on an inotify watch and does not seem to do much of anything else.

% strace -ffp 4012
strace: Process 4012 attached with 4 threads
[pid  4084] restart_syscall(<... resuming interrupted read ...> <unfinished ...>
[pid  4072] restart_syscall(<... resuming interrupted read ...> <unfinished ...>
[pid  4051] restart_syscall(<... resuming interrupted read ...> <unfinished ...>
[pid  4012] restart_syscall(<... resuming interrupted read ...>

 <unfinished ...>
[pid  4051] <... restart_syscall resumed>) = 1
[pid  4051] recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2=\26d\230\340\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0 \1\4\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  4051] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4012] <... restart_syscall resumed>) = 1
[pid  4012] read(5,  <unfinished ...>
[pid  4051] poll([{fd=3, events=POLLIN}], 1, -1 <unfinished ...>
[pid  4012] <... read resumed>"\1\0\0\0\0\0\0\0", 16) = 8
[pid  4012] poll([{fd=5, events=POLLIN}, {fd=11, events=POLLIN}], 2, 1703 <unfinished ...>
[pid  4051] <... poll resumed>)         = 1 ([{fd=3, revents=POLLIN}])
[pid  4051] recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="U\2=\26\304\230\340\1\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \1\5\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  4051] write(5, "\1\0\0\0\0\0\0\0", 8) = 8
[pid  4051] poll([{fd=3, events=POLLIN}], 1, -1 <unfinished ...>
[pid  4012] <... poll resumed>)         = 1 ([{fd=5, revents=POLLIN}])
[pid  4012] read(5, "\1\0\0\0\0\0\0\0", 16) = 8

It is an inotify watch:

% /proc/4012/fd> ls -l 11
lr-x------ 1 martin martin 64 Jun  5 17:30 11 -> anon_inode:inotify


EXPECTED RESULT

Maildir resource does not get stuck.

Also… Akonadi never ever blocks requests of KMail for the payload of a mail. Cause then the user waits. But this is another issue and I believe it has been reported already. Maybe it was me reporting it quite some time ago. A background task *never ever* is more important than what the user wants now.


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: Debian Unstable
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.70
Qt Version: 5.12

ADDITIONAL INFORMATION

The bug about akonadi_maildir_resource being slow is bug #422336. I will add some information there as well.
Comment 1 phil-deb1.merlin@laposte.net 2020-06-09 17:05:35 UTC
Its same problem when you use Mysql
Comment 2 Martin Steigerwald 2020-06-09 17:12:18 UTC
Dear Philippe. Thanks for confirming.