On Sunday 08 December 2019 04:16:10 deloptes wrote: > David C. Rankin wrote: > > 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 > 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>