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 -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>