Message: previous - next
Month: October 2019

Re: [BULK] [trinity-users] Re: ignored kmail crash reports.

From: Gene Heskett <gheskett@...>
Date: Tue, 15 Oct 2019 15:08:34 -0400
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

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 <>