Recently, I wrote about my adventures in troubleshooting Mu4e. This is an update on what I discovered and what I did to resolve the problem. The chances are good that this won’t be of interest to anyone but I’m writing it down in case someone else has the same type of problems now or in the future.
The first thing I did was turn mu4e-index-cleanup off and mu4e-index-lazy-check on to speed up the reindexing. That turned out to be key to understanding what was going on. I noticed that with mu4e-index-cleanup off 2–3 thousand entries were being added to the store each time mu ran. That explained why mds (the spotlight indexer) was being kicked off each time mu ran. I turned mu4e-index-cleanup back on and the indexing was a bit faster than before I began with just mu4e-index-lazy-check on but mu was still running much longer than it should.
Next I noticed that mu.log in ~/.cache/mu/ had several entries like
2020-08-08 08:38:11 [WARN] cannot access /Users/jcs/Maildir/icloud/Trash/cur/1596883130.32552_36.Manfred:2,DS#T: No such file or directory
and that some entries in the Trash mailbox had impossible dates of 1969. There was obviously some problem in the Trash mailbox that was causing problems with the indexing.
I thought about deleting Maildir and downloading everything again from the IMAP server. There were a couple of problems with that, though. First it takes a long time and can be fussy. Second, I was worried that it might affect the renaming of posts and the links that point to them.
I finally just deleted the Trash mailbox, reinitialized the Xapian database, and ran index. That has apparently fixed all the problems. Mu4e is speedy again and even the CPU load has decreased from about 7% to 2%–3% when the system is idling.
I was lucky that the problems were in the Trash mailbox rather than in the one that holds all my saved emails. Regardless, if you have similar problems, I hope this post will help you track down what’s going on.