On Monday 09 December 2019 20:45:33 David C. Rankin wrote:
On 12/08/2019 06:46 AM, Gene Heskett wrote:
I don't see a thing there that kmail should get a tummy ache over. That script has been running daily for close to 20 years now. If fetchmail is running, incoming mail is handled automaticly by sending kmail a check mail message over the dcop or dbus message bus. All kmail has to do is retrieve anything procmail has put in /var/spool/mail/* and sort it to the correct folder. Since kmail is single-threaded, thats maybe a 200 ms freeze of the composer while it's doing that. The only independent thread seems to be the parent thread doing the indexing as killing it kills the other kmail instances seen by htop. 5 total, but the other 4 never record any cpu time.
Computers should save you work, not make it, so I write scripts to automate it.
Thank you deloptes.
Cheers, Gene Heskett
I do the same thing with spamassassin but utilizing 4-folders:
spam spam-learn spam-probably spam-unlearn
where spamassassin drops potential spam in spam-probabaly. I look through it and move what is spam to spam-learn (where it is processed by sa-learn and moved to spam automatically) and move what isn't spam to spam-unlearn where unlearn is run on it and it is put back in the inbox.
The key here, and in your case, the movement of mail between folders should not be causing a reindexing of your entire mail store. If that is what is happening, then that is the bug that should be looked at and confirmed.
Well, since this is kmail 1.9, mostly written in 32 bit days, and moving about half of the debian list to an out of kmail directory, the problem has not re-surfaced, so I am more than ever convinced its triggered by a 32 bit overflow someplace.
Where, I've no clue, but I suspect a concerted effort to bring it into the 64 bit world would pay stability dividends over the next several years.
Cheers, Gene Heskett