11 Jan
2019
11 Jan
'19
3:10 p.m.
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. So some sort of an I'm busy advisory popup might prevent
me from starting another copy. Leave it up until the main window is
opened and its ready for business.
Thank you.
Cheers, Gene Heskett
--
11 Jan
11 Jan
3:21 p.m.
New subject: [trinity-users] kmail, next update request?
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
4:16 p.m.
New subject: [trinity-users] kmail, next update request?
On Friday 11 January 2019 10:21:43 Stefan Krusche wrote:
Am Freitag, 11. Januar 2019 schrieb Gene Heskett:
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.
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
---------------------------------------------------------------------
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
--
12 Jan
12 Jan
7:24 p.m.
New subject: [trinity-users] kmail, next update request?
On Friday 11 January 2019 11:16:51 Gene Heskett wrote:
Cheers, Gene Heskett
--
On Friday 11 January 2019 10:21:43 Stefan Krusche
wrote:
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.
Am Freitag, 11. Januar 2019 schrieb Gene
Heskett:
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.
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
--------------------------------------------------------------------
- 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
7:45 p.m.
New subject: [trinity-users] kmail, next update request?
On Saturday 12 January 2019 14:24:30 Gene Heskett wrote:
Cheers, Gene Heskett
Cheers, Gene Heskett
--
On Friday 11 January 2019 11:16:51 Gene Heskett
wrote:
Another bit of info: mc see's the dot directories, and in exploring for
oddball trash, I found indice files that were not related to the
directory they were in and I deleted them all, then restarted kmail,
which of course complained about this "emc" directories indice file, so
I assume it would rebuild, then open kmails gui. But when it had done
so, there is not an indice file visible, so I am now wondering if all
these empty directories can be nuked.
But before I do that, I'll restart kmail again to see if it now complains
about the emc directory.
On Friday 11 January 2019 10:21:43 Stefan Krusche
wrote:
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.
Am Freitag, 11. Januar 2019 schrieb Gene
Heskett:
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. 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
------------------------------------------------------------------
-- - 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
7:48 p.m.
New subject: [trinity-users] kmail, next update request?
On Saturday 12 January 2019 14:45:18 Gene Heskett wrote:
Cheers, Gene Heskett
Cheers, Gene Heskett
Cheers, Gene Heskett
--
On Saturday 12 January 2019 14:24:30 Gene Heskett
wrote:
No, the restart was clean, no complaints.
I'm going to get rid of the now
empty dot directories next.
On Friday 11 January 2019 11:16:51 Gene Heskett
wrote:
Another bit of info: mc see's the dot directories, and in exploring
for oddball trash, I found indice files that were not related to the
directory they were in and I deleted them all, then restarted kmail,
which of course complained about this "emc" directories indice file,
so I assume it would rebuild, then open kmails gui. But when it had
done so, there is not an indice file visible, so I am now wondering if
all these empty directories can be nuked.
But before I do that, I'll restart kmail again to see if it now
complains about the emc directory. On Friday 11 January 2019 10:21:43 Stefan Krusche
wrote:
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. 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.
----------------------------------------------------------------
-- -- - 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 
9:13 p.m.
Gene Heskett wrote:
In general you are not supposed to work directly with the directories - use
the interface - this is my approach to kmail, but I also use kontact and
not kmail directly. My mail is on the mailserver(s) - I have setup also one
local and since then it is a blessing (dovecot IMAP - took me a while to
configure). I came across dbmail some years ago, but never had the chance
to try it myself - it looks even better than dovecot.
I don't know how you handle your mails and why you should have them
somewhere around.
An error I made many years ago is to mix up the directory where imap was
writing and where the local mails were written by kmail - if you have
something messing up in between could cause a lot of headache. Since I put
it right no issues, but also all mails go to exim/dovecot.
hope it helps
Another bit of
info: mc see's the dot directories, and in exploring
for oddball trash, I found indice files that were not related to the
directory they were in and I deleted them all, then restarted kmail,
which of course complained about this "emc" directories indice file,
so I assume it would rebuild, then open kmails gui. But when it had
done so, there is not an indice file visible, so I am now wondering if
all these empty directories can be nuked.
But before I do that, I'll restart kmail again to see if it now
complains about the emc directory.
No, the restart was clean, no complaints.
I'm going to get rid of the now
empty dot directories next.
13 Jan
13 Jan
4:10 a.m.
New subject: [trinity-users] Re: kmail, next update request?
On Saturday 12 January 2019 16:13:21 deloptes wrote:
Gene Heskett wrote:
In general you are not supposed to work directly with the directories
- use the interface - this is my approach to kmail, but I also use
kontact and not kmail directly. My mail is on the mailserver(s) - I
have setup also one local and since then it is a blessing (dovecot
IMAP - took me a while to configure). I came across dbmail some years
ago, but never had the chance to try it myself - it looks even better
than dovecot.
I don't know how you handle your mails and why you should have them
somewhere around.
An error I made many years ago is to mix up the directory where imap
was writing and where the local mails were written by kmail - if you
have something messing up in between could cause a lot of headache.
Since I put it right no issues, but also all mails go to exim/dovecot.
hope it helps
Probably not much in this case as I keep those emails I might need to go
back and consult again locally for future reference in case the network
goes toes up or face down. Some folders don't have an expire at all and
go back 17 years. I think I have it sorted for the time being. But
problems like this are more often found by code checkers than by humans
and I've been around this circus for long enough to both know, and
accept that finding something as exotic as this, in a code base this
old, is probably impossible.
Thanks for being concerned, I do appreciate it.
Another
bit of info: mc see's the dot directories, and in exploring
for oddball trash, I found indice files that were not related to
the directory they were in and I deleted them all, then restarted
kmail, which of course complained about this "emc" directories
indice file, so I assume it would rebuild, then open kmails gui.
But when it had done so, there is not an indice file visible, so I
am now wondering if all these empty directories can be nuked.
But before I do that, I'll restart kmail again to see if it now
complains about the emc directory.
No, the restart was clean, no complaints. I'm going to get rid of
the now empty dot directories next.
---------------------------------------------------------------------
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
--
19 Jan
19 Jan
2:22 a.m.
New subject: [trinity-users] Re: kmail, next update request?
On Saturday 12 January 2019 23:10:59 Gene Heskett wrote:
Thanks for being concerned, I do appreciate it.
Now I am about to reboot. Because I have 2 copies of kdesktop spinning
at 100% and running my cpu up to 44C. According to htop, for 18 hours
now.
And according to gkrellm, stuck on cpu0. And after 12 days of uptime I am
just short of 500 megs into swap. Normally maybe 20 megs ib 2 weeks..
I take it back, it just switched to cpu1.
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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
2:53 a.m.
New subject: [trinity-users] Re: kmail, next update request?
On Friday 18 January 2019 21:22:42 Gene Heskett wrote:
On Saturday 12 January 2019 23:10:59 Gene Heskett
wrote:
Rebooted, looks like its back to normal. No clue what brought that on.
Thanks for being concerned, I do appreciate it.
Now I am about to reboot. Because I have 2 copies of kdesktop
spinning at 100% and running my cpu up to 44C. According to htop, for
18 hours now.
And according to gkrellm, stuck on cpu0. And after 12 days of uptime I
am just short of 500 megs into swap. Normally maybe 20 megs ib 2
weeks..
I take it back, it just switched to cpu1.
Cheers, Gene Heskett
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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
2164
days inactive
2172
days old
9 comments
3 participants
participants (3)
-
deloptes -
Gene Heskett -
Stefan Krusche