8 Dec
2019
8 Dec
'19
12:46 p.m.
On Sunday 08 December 2019 04:16:10 deloptes wrote:
David C. Rankin wrote:
I manually drag and drop spam into a spam folder at random times using
kmails own message mover. I have a cron script that stops fetchmail, and
then runs sa-learn over that, and moves those 15 or less messages to
another folder kmail can see called spam-hold, emptying it before the
move so that stuff has an additional day to live in case I want it back.
That is the extent of _my_ putzing with its data.
That script:
==============================
#!/bin/bash
PATH=/sbin:/root/bin:/usr/bin:/bin:/home/gene/bin
# make this run as gene!
# make sure the database is free
killall fetchmail
# wait for the spamd pipes to drain
sleep 20
# do this dastardly deed
sa-learn --ham /home/gene/Mail/ham/cur
sa-learn --ham /home/gene/Mail/coco/cur
sa-learn --ham /home/gene/Mail/Xorg/cur
sa-learn --spam /home/gene/Mail/spam/cur
# now, this stuff is trash, 24 hours old, kill it.
rm -f /home/gene/Mail/spam-hold/cur/*
# And move todays catch into Mail/spam-hold/cur for a 24 hour period
# so I can retrieve it the next day if needed.
mv /home/gene/Mail/spam/cur/* /home/gene/Mail/spam-hold/cur/
# Note, I leave the ham for moving where it really goes
# and restore fetchmail but let the disks synch first
sleep 6
/usr/bin/fetchmail -d 120 --fetchmailrc /home/gene/.fetchmailrc
==============================
I don't see a thing there that kmail should get a tummy ache over. That
script has been running daily for close to 20 years now. If fetchmail is
running, incoming mail is handled automaticly by sending kmail a check
mail message over the dcop or dbus message bus. All kmail has to do is
retrieve anything procmail has put in /var/spool/mail/* and sort it to
the correct folder. Since kmail is single-threaded, thats maybe a 200 ms
freeze of the composer while it's doing that. The only independent
thread seems to be the parent thread doing the indexing as killing it
kills the other kmail instances seen by htop. 5 total, but the other 4
never record any cpu time.
Computers should save you work, not make it, so I write scripts to
automate it.
Thank you deloptes.
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>
Yes,
I've followed on and off your kmail woes. From what you describe
this is a bug that should be fixed. kmail should not continually be
putting a load on the system resorting indexes, etc.. There should
be debugging that can be cranked up to cause TDE to spit out INFO
level messages for kmail that may give a better picture of what is
going on.
If the problem is that your mail store is too big for kmail to
handle without thinking it needs to reindex -- that's still a bug
and whether it is a Qt3 issue or kmail issue, both should be
solveable today. (just off hand I can see if a limit is INT_MAX how
a 20G mail store would be an issue), Regardless, whatever it
triggering the reindexing needs to be identified.
Whatever was burning up the cores on your old box -- is still
causing the same mischief on your new box -- it's just doing a whole
lot more mischief a whole lot faster now....
I also think his archive is too big and also I think he's touching
mails directly or with something else, causing the reindexing,
although only hypothesis.
It could be also a bug - but how can one reproduce it?
regards