Greetings;
I just noticed that 1 of the 2 lists I had sorted into subdirs by the year, was placing new incoming messages in a subdir I had prepared to hold the 2019 messges, even though the filter rules said to put new incoming that matched that filer rule, into the main folder.
So I shift marked the 2019 folders content a month at a time and drug it back to the main emc folder, leaving the 2019 folder empty, so I deleted in and its 3 subdirs. This of course crashed kmail. On restart, its now doing 95%+ but is doing it for only a few milliseconds per core, switching faster than gkrellm can accurately track. But for some reason its skipping core2? ?? ??? And then it crashed again, and I submitted that report. Now on the restart, which nicely saved this message, its back to using all 4 cores for a couple seconds each. But I mentioned it, so it just stuck on core0 for about 15 seconds.
Now trying to get some clues from lsof and a few filter stages of grep, I find one instance per year for the emc folder, but the other, "coco" folder and all its subdirs will need a final |wc -l showing 170 instances. I just found I'd not nukes the coco's 2019 indice stuff, so one more restart. But I'll send this first...
Cheers, Gene Heskett
On Saturday 19 October 2019 07:22:05 Gene Heskett wrote:
Greetings;
I just noticed that 1 of the 2 lists I had sorted into subdirs by the year, was placing new incoming messages in a subdir I had prepared to hold the 2019 messges, even though the filter rules said to put new incoming that matched that filer rule, into the main folder.
So I shift marked the 2019 folders content a month at a time and drug it back to the main emc folder, leaving the 2019 folder empty, so I deleted in and its 3 subdirs. This of course crashed kmail. On restart, its now doing 95%+ but is doing it for only a few milliseconds per core, switching faster than gkrellm can accurately track. But for some reason its skipping core2? ?? ??? And then it crashed again, and I submitted that report. Now on the restart, which nicely saved this message, its back to using all 4 cores for a couple seconds each. But I mentioned it, so it just stuck on core0 for about 15 seconds.
Now trying to get some clues from lsof and a few filter stages of grep, I find one instance per year for the emc folder, but the other, "coco" folder and all its subdirs will need a final |wc -l showing 170 instances. I just found I'd not nukes the coco's 2019 indice stuff, so one more restart. But I'll send this first...
3 hours later its behaving itself. Nothing from kmail is now anywhere near the top of an htop list. cpu temps are down about 8C. I think I've fixed it!
Cheers, Gene Heskett
Cheers, Gene Heskett
Gene Heskett wrote:
3 hours later its behaving itself. Nothing from kmail is now anywhere near the top of an htop list. cpu temps are down about 8C. I think I've fixed it!
Gene, it is what I said before - you should never ever mess up with the Maildir content, except via a single interface, be it imap, or kmail. Let only one application work at a time.
regards
On Saturday 19 October 2019 13:54:54 deloptes wrote:
Gene Heskett wrote:
3 hours later its behaving itself. Nothing from kmail is now anywhere near the top of an htop list. cpu temps are down about 8C. I think I've fixed it!
Gene, it is what I said before - you should never ever mess up with the Maildir content, except via a single interface, be it imap, or kmail. Let only one application work at a time.
regards
But no one has answered my question about how do I move a directory's contents en-mass to another directory by way of a dbus command. I need to move the contents of the spam directory by first deleting the contents of the spam-hold directory, and the move the contents of the spam directory into the spam-hold directory, a thing that is repeated each 24 hours by the script that drives sa-learn spam, and sa-learn ham over selected directory's.
I had to pull teeth w/o novocain just to find out how to send kmail a go get mail command from my mailwatcher script, which uses inotifywait to see the closing of a mailfile in /var/spool/mail as its indicator that a new mail has arrived from a separate fetchmail->procmail process.
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
On Saturday 19 October 2019 15:03:49 Gene Heskett wrote:
On Saturday 19 October 2019 13:54:54 deloptes wrote:
Gene Heskett wrote:
3 hours later its behaving itself. Nothing from kmail is now anywhere near the top of an htop list. cpu temps are down about 8C. I think I've fixed it!
Gene, it is what I said before - you should never ever mess up with the Maildir content, except via a single interface, be it imap, or kmail. Let only one application work at a time.
regards
But no one has answered my question about how do I move a directory's contents en-mass to another directory by way of a dbus command. I need to move the contents of the spam directory by first deleting the contents of the spam-hold directory, and the move the contents of the spam directory into the spam-hold directory, a thing that is repeated each 24 hours by the script that drives sa-learn spam, and sa-learn ham over selected directory's.
I had to pull teeth w/o novocain just to find out how to send kmail a go get mail command from my mailwatcher script, which uses inotifywait to see the closing of a mailfile in /var/spool/mail as its indicator that a new mail has arrived from a separate fetchmail->procmail process.
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
Need washrag to remove egg on face. At the time I wrote it there was a battle going on as some distro's use dcop, and some dbus. It appears that in debian, dcop won that particular war, so thats what I'm using, and its coded like this:
Method=dcop if [[ ${Method} = 'dbus' ]] then Cmd="/usr/bin/qdbus org.kde.kmail /KMail org.kde.kmail.kmail.checkMail" fi if [[ ${Method} = 'dcop' ]] then #or for dcop, use: Cmd="/opt/trinity/bin/dcop kmail KMailIface checkMail" fi [... skip some other alternative hpusekeeping options] if test "${InMail}" = "gene" then $Cmd [...]
So thats the extent of my dcop training. The manpage for dcop is so incomplete its worthless. Hardly a full screenfull of very generalized info.
What dcop can do for|to kmail should be in the kmail handbook, but there seems to not even be the word dcop. Where can I access what will fix that lack?
- To unsubscribe, e-mail:
trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Cheers, Gene Heskett
Gene Heskett wrote:
Need washrag to remove egg on face. At the time I wrote it there was a battle going on as some distro's use dcop, and some dbus. It appears that in debian, dcop won that particular war, so thats what I'm using, and its coded like this:
Method=dcop if [[ ${Method} = 'dbus' ]] then Cmd="/usr/bin/qdbus org.kde.kmail /KMail org.kde.kmail.kmail.checkMail" fi if [[ ${Method} = 'dcop' ]] then #or for dcop, use: Cmd="/opt/trinity/bin/dcop kmail KMailIface checkMail" fi [... skip some other alternative hpusekeeping options] if test "${InMail}" = "gene" then $Cmd [...]
So thats the extent of my dcop training. The manpage for dcop is so incomplete its worthless. Hardly a full screenfull of very generalized info.
What dcop can do for|to kmail should be in the kmail handbook, but there seems to not even be the word dcop. Where can I access what will fix that lack?
Let be more precise here - in your first if method you do something for kde4 or kde5 not tde. In kde3 and later in tde dcop is the message buss/interface between different applications. DBus emerged later and won the public, so kde4 and kde5 also gnome and most of the modern systems use it. I think the best way is to examine what interfaces are provided by which application in dcop. Maybe kdcop will help you.
https://api.kde.org/3.5-api/kdelibs-apidocs/dcop/html/index.html
and some background here https://www.osnews.com/story/14768/kde-says-goodbye-to-dcop/
On Saturday 19 October 2019 02:03:49 pm Gene Heskett wrote:
On Saturday 19 October 2019 13:54:54 deloptes wrote:
Gene Heskett wrote:
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
I always did dbus by trial and error. The command line really, really sucks, so try to find a GUI tool to test with and then it’s fairly easy to translate what works to command line for your scripts.
I used qdbusviewer in the past, it worked well but I think it’s dead?
I’ve seen D-Feet [1] referenced, never used it. https://wiki.gnome.org/action/show/Apps/DFeet
Here’s stack’s answer to “DBUS Message/Signal Viewer Tools”
On Saturday 19 October 2019 15:30:44 Michael wrote:
On Saturday 19 October 2019 02:03:49 pm Gene Heskett wrote:
On Saturday 19 October 2019 13:54:54 deloptes wrote:
Gene Heskett wrote:
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
I always did dbus by trial and error. The command line really, really sucks, so try to find a GUI tool to test with and then it’s fairly easy to translate what works to command line for your scripts.
I used qdbusviewer in the past, it worked well but I think it’s dead?
I’ve seen D-Feet [1] referenced, never used it. https://wiki.gnome.org/action/show/Apps/DFeet
Here’s stack’s answer to “DBUS Message/Signal Viewer Tools”
But there is no corresponding tome on dcop, but I did eventually stumble over kdcop, which is tde's version of kdcop, the only apparent diff being a tde credit line at the top of the file. This seems to give a couple of command lists when expanded, showing expected synatx to use.
But kdcop claims they all have a null return. Sensibly for instance when you query for a list, one would expect at least a csv style list to be returned to the shell requesting the list. So the utility itself is incomplete, or kmails responce code was never written. And the tde handbooks entry for dcop is a one page apology because the handbook for dcop has never been written.
And that only confirms my opinion of Ingo Klocker's inability to herd the bunch of cats he is in charge of at kde, to get the docs written and bugs fixed. Only truly showstopper bugs were ever looked at, and sometimes fixed. Thats why tde was forked in the first place, and lots of bugs have since been fixed. Thats rather hugely appreciated at this campsite.
But is there any realistic hope of fixing kdcop and getting its Docs? written too? That last can be exceedingly difficult without figuratively installing an rj45 jack into the original coders brain.
Been there, done that, lots of frustration trying to "get into the authors brain" while running down and fixing his mistakes. Having done that quite a few times when carving code was much simpler, I now, at 85 yo, bow down in awe of those who can do it. And you'll get a hand cooler if you show up at my front door, even if its my last one...
Thank you all.
Cheers, Gene Heskett
Gene Heskett wrote:
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
Let be clear only few applications in TDE use dbus and these are the once that need interaction with dbus for some reason - kmail has nothing to do with dbus.
You should think of using pipes - I do not mean the unix '|' but in your process. One application works on content in one directory and delivers the output into another directory, where other application uses this as input and delivers to another directory.
On Saturday 19 October 2019 17:46:42 deloptes wrote:
Gene Heskett wrote:
If those rm's and mv's from outside of kmails knowledge, were converted to dbus commands to be executed by kmail, then nothing would disturb its database but kmails own actions.
So, where do I find the real docs on how kmail responds to commands sent over dbus? That seems to be a secret, and it sucks dead toads thru soda straws. I just now rechecked the Handbook, and it has zero mention of dbus. So please explain how, and I WILL fix my scripts.
Let be clear only few applications in TDE use dbus and these are the once that need interaction with dbus for some reason - kmail has nothing to do with dbus.
You should think of using pipes - I do not mean the unix '|' but in your process. One application works on content in one directory and delivers the output into another directory, where other application uses this as input and delivers to another directory.
Humm, how would one translate this to that?
#!/bin/bash PATH=/sbin:/root/bin:/usr/bin:/bin:/home/gene/bin # make this run as gene! Does # 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 by hand # and restore fetchmail but let the disks synch first sleep 6 /usr/bin/fetchmail -d 120 --fetchmailrc /home/gene/.fetchmailrc
Simple little script, usually takes about a minute to run. cron sends me an email. I delete it unless there has been an error.
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Gene Heskett wrote:
Humm, how would one translate this to that?
#!/bin/bash PATH=/sbin:/root/bin:/usr/bin:/bin:/home/gene/bin # make this run as gene! Does # 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 by hand # and restore fetchmail but let the disks synch first sleep 6 /usr/bin/fetchmail -d 120 --fetchmailrc /home/gene/.fetchmailrc
Simple little script, usually takes about a minute to run. cron sends me an email. I delete it unless there has been an error.
I don't know. I use exim with sa and bogofilter. Then it goes to imap and kmail reads from that imap server.
On Saturday 19 October 2019 06:22:05 am Gene Heskett wrote:
some KMail woes...
Hi Gene,
I’ve sporadically always had KMail (TDE) use 100% of a CPU upon startup and it almost always crashes the first time I try to use the quick “Search:” (below the toolbar). Oddly once it crashes the first time and gets restarted search works fine. Couple thoughts tangentially related to your posts:
- Do you have any filters that check by datetimes?
I once had a filter, that was suppose to only be upon income mail, setup to trash anything older than 400 days. Whatever caused it, it didn’t always function correctly and would (seemingly randomly) trash items in folders older than 400 days. I’m sure there was some user error I was committing, but I removed it after having to restore from backups one too many times.
- Have you checked the filters that reference the folders not getting mail sorted to them properly?
I just moved several sub-folders to new main branches. About half of them started dumping their mail into the main inbox. Upon investigation the target for the Filter Actions, Move Into Folder was broken. (It’s obvious, says something like folder not found.)
Again, not sure if this helps you directly, but maybe it’ll give you an extra clue to tracking your issues down.
Best, Michael
On Saturday 19 October 2019 15:18:39 Michael wrote:
On Saturday 19 October 2019 06:22:05 am Gene Heskett wrote:
some KMail woes...
Hi Gene,
I’ve sporadically always had KMail (TDE) use 100% of a CPU upon startup and it almost always crashes the first time I try to use the quick “Search:” (below the toolbar). Oddly once it crashes the first time and gets restarted search works fine. Couple thoughts tangentially related to your posts:
- Do you have any filters that check by datetimes?
I once had a filter, that was suppose to only be upon income mail, setup to trash anything older than 400 days. Whatever caused it, it didn’t always function correctly and would (seemingly randomly) trash items in folders older than 400 days. I’m sure there was some user error I was committing, but I removed it after having to restore from backups one too many times.
- Have you checked the filters that reference the folders not getting
mail sorted to them properly?
I just moved several sub-folders to new main branches. About half of them started dumping their mail into the main inbox. Upon investigation the target for the Filter Actions, Move Into Folder was broken. (It’s obvious, says something like folder not found.)
Again, not sure if this helps you directly, but maybe it’ll give you an extra clue to tracking your issues down.
Best, Michael
I'm sure this would be helpfull, if this $datetime was a problem, but there are no such filters using it.
Cheers, Gene Heskett
-
deloptes -
Gene Heskett -
Michael