On Friday 11 January 2019 10:21:43 Stefan Krusche
wrote:
Am Freitag, 11. Januar 2019 schrieb Gene
Heskett:
Greetings all;
On the next kmail update would it be possible to add a popup for
the case of the indice fixing when it gets lost?
The time lag between clicking on the OK in that event, can be long
enough you've forgotten you started kmail once already, and its
cpu load while doing that is quite minimal, and I suspect half or
more of my indice problems are probably caused by two copies of
kmail fighting over the indice files.
Hi Gene,
are you really sure you have two instances of kmail running under
that circumstances?! I have never seen two instances running
simultaneously. When I try to launch a second instance of kmail it
doesn't do so, it just switches to the already running instance…
M2C
Kind regards,
Stefan
Well, I just had htop send a terminate to the highest process # of 5
copies of kmail it can see. Killed it all.
Restarted it from the tde most popular app list, see 2 copies running
with both useing some cpu. and it reports the same bad index for one
folder at restart. At this point I see 2 copies of kmail running, but
when it has rebuilt the index for the emc directory, which currently
holds a bit north of 58k messages, then I see 5 copies running, but
only the first copy is actually showing cpu time. And its
resurrecting read messages as new, unread. I can cycle thru them,
reducing the unread count to zero, but then go to another list, and
come back after having read its unread, and by then this folder has
the same 3 (could be 40+) that I've already read and replied to, are
once again marked unread. I've checked perms and such but I own the
whole several gigabyte corpus of email, so I can't point any fingers
at that for a cause.
So whats doing it?
This has been over the years, an ongoing problem when the number of
messages in a given directory is in the modulo 60000 range. I have
another list thats nearly 130k messages, gave me an identical problem
for about a month about 18 months back. Then it got well, and hasn't
done it in quite a spell now. Note that I abuse kmail a bit, I do have
a procmail recipe or 3 that put bad stuff directly in the spam folder,
and an sa-learn script that cleans out the spam-hold directory, feeds
the spam to sa-learn and then moves the spam to a spam-hold folder
that I review daily in case I want to rescue something miss-filed, so
I am used to a spam and spam-hold index's needing a rebuild, but thats
rarely more than 10 messages in either folder so that pair of indices
being rebuilt is only a second or so
Now this started up about a week ago. And I thought maybe this was a
good time to see if we can spot the rat somehow.
Further info: A read email in this directory doesn't get a :2,S appended
to its filename. Adding that by hand converts it into a read mail,
apparently forever.
What can be made of that? The directory currently has:
gene@coyote:~/Mail/emc/cur$ ls -l |wc -l
58868
files in it.
But another even bigger directory:
gene@coyote:~/Mail/emc/cur$ ls -l ../../coco/cur|wc -l
107784
has no such problems now for several years. It did have a similar problem
when it was about that size back when it was the old kde version.
--------------------------------------------------------------------
- To unsubscribe, e-mail:
trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional
commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net Read
list messages on the web archive:
http://trinity-users.pearsoncomputing.net/ Please remember not to
top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett