On Tuesday 15 October 2019 13:45:14 deloptes wrote:
Gene Heskett wrote:
Greetings all;
Hi Gene,
Are you send those to /dev/null? I've sent a whole bunch of them.
I do not know what you are talking about, but I recall you mentioned before you had issues with your mailbox/es.
These crashes always seem to be preceded by a couple days of a kmail session burning up a core of 4 cores, bouncing to the next available core, at 99 to 100% at 15 second or so intervals.
AFAIR you are using local MailDir with tons of mail
yes but its slowly disappearing.
These seem to be related to kmail finding trash files in its database, causing problems while re-indexing. I have two folders which are subfolders with a given years messages manually sorted into that years corpus.
I recall experiencing similar with KDE3 like 12y ago. Unpleasant situation for sure!
When I relaunch kmail after one of these crashes, I am getting advisories that so-and-so has an index problem, and its generally the top level folder, and 2 or 3 of its subfolders that are named. And the older folders are slowly being emptied, as in messages are disappearing despite having no expiry set up.
Can anything be done, or is there something I can check-uncheck someplace?
I don't know exactly, but I know what solved my problems was to setup imap server between the directory structure and the client. The server where the mails are is 4cores/32GB mem, however the server is not very fast - I am not sure why - I suspect the disks are not the fastest, but I do not experience any issue with mails.
I'm currently sucking, with fetchmail, from a dovecot database at my isp, but the procmail direct deposit into the spam folder, which gets mv'd to spam-hold for one day by the same script that has sa-learn spam being done on that folder, moving what it has looked at to spam-hold. Thats the only non-kmail accesses that I have programmed. Any other incoming mail is deposited in /var/mail, and dbus sends kmail a check local folder message for new mail by way of inotifywait seeing the closing of the mail file and triggering the dbus message. The locale /var/mail/mailfile generally has a lifetime in the non-zero length state of milliseconds.
Few years ago I integrated dbmail for a customer. It is extremely fast. Think about migrating those tons of mails.
describe that please.
I know it is not exactly an answer, but I can not think of any other. As for kmail I have not looked into it in detail, but it is complex - one has to be able to reproduce the problem to help you find a solution.
Also are you sure nothing else is using your local Maildir? I know you have many scripts for this and that.
procmail may, very occasionally place a particularly nasty bit of stuff directly in the spam folder, but thats not more than a weekly occurrence. If that often. I'll find that recipe and nuke it, just for S&G. Or better yet, send that one to /dev/null. At least I'll have a log entry. Right now, I think I'll go over the /home/gene/Mail dir and nuke every sorted index just for S&G as thats nowhere near universally present. Then I'll exit kmail as the uptime is 29+days, and restart it.
regards
Thanks
Cheers, Gene Heskett