7 Oct
2020
7 Oct
'20
3:24 p.m.
Not horribly important, but whenever KMail checks mail is ‘freezes’ for a bit
and interrupts typing/mouse clicks (just for KMail, rest of system runs
fine).
Would it be hard to make KMail multi-threaded? I’m assuming that’d ‘fix’ the
freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt and put in
a feature request.
Best,
Michael
7 Oct
7 Oct
6:03 p.m.
Michael via tde-users wrote:
Not horribly important, but whenever KMail checks mail
is ‘freezes’ for a
bit and interrupts typing/mouse clicks (just for KMail, rest of system
runs fine).
Would it be hard to make KMail multi-threaded? I’m assuming that’d ‘fix’
the freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt and put
in a feature request.
Explain what you are exactly doing so that someone can reproduce it. I think
it is multithreaded already and the mail checking is done via background
job (if I am not totally wrong it is run in another thread) that has
nothing to do with the GUI. But I am not exactly an expert in the internals
of KMail.
---------------------------------------------------------------------
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
6:40 p.m.
On Wednesday 07 October 2020 01:03:07 pm deloptes via tde-users wrote:
Michael via tde-users wrote:
Ah, sure!
- Start KMail
- Setup ~50 filters.
- Setup mail checking every ~15 minutes [1]
- When KMail checks mail the whole program is 'frozen' until it finishes
checking for mail. [2]
- You can use any other program on the machine with no ill effects.
[1] I average slightly over 50 downloaded messages per 15 minute check.
[2] e.g. If you're in the middle of typing a mail, you can no longer type
anything into KMail. If you try to click on some other folder, nothing
happens. If you drag some other program’s window over KMail, the KMail GUI
gets whitened/blanked out until the mail check stops.
This is on my work machine (info below), so it’s not a 10 year old laptop,
which was why I was thinking it was a multi-thread issue?
Best,
Michael
michael@local [~/.trinity/share/apps/kmail]# du -sh mail
2.6G mail
Computer Info {inxi junk snipped for brevity}:
System:
Host: <filter> Kernel: 4.19.0-11-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
parameters: BOOT_IMAGE=/vmlinuz-4.19.0-11-amd64
root=UUID=<filter> ro
Desktop:
Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: LightDM 1.26.0
Distro: MX-19.2_x64 patito feo May 31 2020 base: Debian GNU/Linux 10 (buster)
Machine:
Type: Desktop Mobo: ASRock model: X470 Taichi serial: <filter>
UEFI: American Megatrends v: P1.50 date: 07/03/2018
CPU:
Topology: 8-Core model: AMD Ryzen 7 2700X bits: 64 type: MT MCP arch: Zen+
Graphics:
Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: Micro-Star MSI driver:
nvidia
v: 418.152.00 bus ID: 2e:00.0 chip ID: 10de:1c03
Display: x11 server: X.Org 1.20.4 driver: nvidia
unloaded: fbdev,modesetting,nouveau,vesa alternate: nv resolution:
1920x1080~60Hz
OpenGL: renderer: GeForce GTX 1060 6GB/PCIe/SSE2 v: 4.6.0 NVIDIA 418.152.00
direct render: Yes
Drives:
Local Storage: total: 11.83 TiB used: 5.04 TiB (42.6%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO 1TB size: 931.51 GiB
Info:
Processes: 412 Uptime: 9d 1h 41m Memory: 62.90 GiB used: 7.99 GiB (12.7%)
Init: SysVinit v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8
Shell: quick-system-in running in: quick-system-in inxi: 3.0.36
Not horribly important, but whenever KMail checks
mail is ‘freezes’ for a
bit and interrupts typing/mouse clicks (just for KMail, rest of system
runs fine).
Would it be hard to make KMail multi-threaded? I’m assuming that’d ‘fix’
the freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt and
put in a feature request.
Explain what you are exactly doing so that someone can reproduce it. I
think it is multithreaded already and the mail checking is done via
background job (if I am not totally wrong it is run in another thread) that
has nothing to do with the GUI. But I am not exactly an expert in the
internals of KMail. 
6:51 p.m.
Anno domini 2020 Wed, 7 Oct 13:40:31 -0500
This is strange. Do you get hundreds of mails in 15 minutes?
Could you run "htop" in a terminal so that you see which program is blocking? It
might be something spawned from kmail or something totally different.
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
[...]
Ah, sure!
- Start KMail
- Setup ~50 filters.
- Setup mail checking every ~15 minutes [1]
- When KMail checks mail the whole program is 'frozen' until it finishes
checking for mail. [2]
- You can use any other program on the machine with no ill effects.
[1] I average slightly over 50 downloaded messages per 15 minute check.
[2] e.g. If you're in the middle of typing a mail, you can no longer type
anything into KMail. If you try to click on some other folder, nothing
happens. If you drag some other program’s window over KMail, the KMail GUI
gets whitened/blanked out until the mail check stops.
This is on my work machine (info below), so it’s not a 10 year old laptop,
which was why I was thinking it was a multi-thread issue?
Best,
Michael
7:44 p.m.
On Wednesday 07 October 2020 01:51:49 pm Dr. Nikolaus Klepp wrote:
Anno domini 2020 Wed, 7 Oct 13:40:31 -0500
Yeah, due to spikiness of things, I’d guess some mail checks get 200-300
mails, some get 10. The average of ~50+ was over the last 15 day period
(75,000 in 15 days if someone wants to check my maths...).
htop attached of KMail at idle. I had the main window and 3 messages open (=
4 child processes?). During a mail check it climbs to 100% CPU% for the
parent KMail row, the children don’t change at all, sits at 100% until it’s
done (1-3 seconds) and then drops back to ~0% CPU%.
My graphical skills lack, headers are:
PID / USER / PRI / NI / VIRT / RES / SHR / S / CPU% / MEM% / TIME+ / Command /
The 0.7 is CPU%
2119M is VIRT
I don’t know htop well enough, but it’d seems CPU% has to be for a single CPU?
Yeah, gotta be, load average: 0.30, 0.20, 0.14, so it’s not doing anything to
even 1 minute load numbers.
Ah, sure!
- Start KMail
- Setup ~50 filters.
- Setup mail checking every ~15 minutes [1]
- When KMail checks mail the whole program is 'frozen' until it finishes
checking for mail. [2]
- You can use any other program on the machine with no ill effects.
[1] I average slightly over 50 downloaded messages per 15 minute check.
[2] e.g. If you're in the middle of typing a mail, you can no longer type
anything into KMail. If you try to click on some other folder, nothing
happens. If you drag some other program’s window over KMail, the KMail
GUI gets whitened/blanked out until the mail check stops.
This is on my work machine (info below), so it’s not a 10 year old
laptop, which was why I was thinking it was a multi-thread issue?
Best,
Michael
This is strange. Do you get hundreds of mails in 15 minutes?
Could you run "htop" in a terminal so that you see which program is
blocking? It might be something spawned from kmail or something totally
different. 
8:55 p.m.
On Wednesday 07 October 2020 11:24:30 Michael via tde-users wrote:
Not horribly important, but whenever KMail checks mail
is ‘freezes’
for a bit and interrupts typing/mouse clicks (just for KMail, rest of
system runs fine).
Would it be hard to make KMail multi-threaded? I’m assuming that’d
‘fix’ the freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt and
put in a feature request.
I was given to understand a decade back by Ingo Kloker that it was going
to be a major rewrite.
So I did the next best thing. using fetchmail I took that job away from
kmail by running as a daemon set to go get any email there might be at
my ISP's mail server, and configured it to use procmail as the MTA. Then
I learned to write recipes for procmail to get rid of the worst of the
spammers, the wrote more recipes to filter incoming thru clamav, and
ditto spamd so at least 75% of that crap goes to /dev/null.
What survives that gauntlet gets dumped into /var/mail/name, and another
scrip has launched inotifywait to watch that buffer location.
Inotifywait exits with the name of the file and my script then uses dbus
to send kmail a get the mail command. And relaunches inotifywait again.
So the freeze is reduced to a few milliseconds while it gets that
incoming mail and sorts it to the correct folder.
Sounds a bit complex but it all Just Works. 2 mouse clicks to answer a
message as I am doing now. Whats not to like?
Best,
Michael
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinity
desktop.org
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>
9:27 p.m.
On Wednesday 07 October 2020 13:55:23 Gene Heskett via tde-users wrote:
On Wednesday 07 October 2020 11:24:30 Michael via
tde-users wrote:
Hi, Gene!
I want to be just like you when I grow up.
Bill
Not horribly important, but whenever KMail checks
mail is ‘freezes’
for a bit and interrupts typing/mouse clicks (just for KMail, rest of
system runs fine).
Would it be hard to make KMail multi-threaded? I’m assuming that’d
‘fix’ the freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt and
put in a feature request.
I was given to understand a decade back by Ingo Kloker that it was going
to be a major rewrite.
So I did the next best thing. using fetchmail I took that job away from
kmail by running as a daemon set to go get any email there might be at
my ISP's mail server, and configured it to use procmail as the MTA. Then
I learned to write recipes for procmail to get rid of the worst of the
spammers, the wrote more recipes to filter incoming thru clamav, and
ditto spamd so at least 75% of that crap goes to /dev/null.
What survives that gauntlet gets dumped into /var/mail/name, and another
scrip has launched inotifywait to watch that buffer location.
Inotifywait exits with the name of the file and my script then uses dbus
to send kmail a get the mail command. And relaunches inotifywait again.
So the freeze is reduced to a few milliseconds while it gets that
incoming mail and sorts it to the correct folder.
Sounds a bit complex but it all Just Works. 2 mouse clicks to answer a
message as I am doing now. Whats not to like?
Cheers, Gene Heskett
9:45 p.m.
Michael via tde-users wrote:
On Wednesday 07 October 2020 01:51:49 pm Dr. Nikolaus
Klepp wrote:
I think this is a use case specific issue and has probably to do with the
number of filters. I am not sure how and where they are executed, but it
sounds like the GUI is blocked until something executes in the background.
I would not say it is related to the retrieving of the mails as a process
but most probably in something after the message is already there.
You could use tcpdump and wireshark to see the timeline for example.
You probably don't have the debug package installed, but if it is there you
could enable debugging for kmail and some tdeio like pop3 or imap etc.
Restart kmail and see what the log says.
I don't have any better idea for now.
BTW it's also not clear which protocol you use - POP/IMAP?
---------------------------------------------------------------------
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
Anno domini 2020 Wed, 7 Oct 13:40:31 -0500
Yeah, due to spikiness of things, I’d guess some mail checks get 200-300
mails, some get 10. The average of ~50+ was over the last 15 day period
(75,000 in 15 days if someone wants to check my maths...).
htop attached of KMail at idle. I had the main window and 3 messages open
(=
4 child processes?). During a mail check it climbs to 100% CPU% for the
parent KMail row, the children don’t change at all, sits at 100% until
it’s done (1-3 seconds) and then drops back to ~0% CPU%.
My graphical skills lack, headers are:
PID / USER / PRI / NI / VIRT / RES / SHR / S / CPU% / MEM% / TIME+ /
Command /
The 0.7 is CPU%
2119M is VIRT
I don’t know htop well enough, but it’d seems CPU% has to be for a single
CPU? Yeah, gotta be, load average: 0.30, 0.20, 0.14, so it’s not doing
anything to even 1 minute load numbers. Ah, sure!
- Start KMail
- Setup ~50 filters.
- Setup mail checking every ~15 minutes [1]
- When KMail checks mail the whole program is 'frozen' until it
finishes checking for mail. [2]
- You can use any other program on the machine with no ill effects.
[1] I average slightly over 50 downloaded messages per 15 minute check.
[2] e.g. If you're in the middle of typing a mail, you can no longer
[type
anything into KMail. If you try to click on some other folder, nothing
happens. If you drag some other program’s window over KMail, the KMail
GUI gets whitened/blanked out until the mail check stops.
This is on my work machine (info below), so it’s not a 10 year old
laptop, which was why I was thinking it was a multi-thread issue?
Best,
Michael
This is strange. Do you get hundreds of mails in 15 minutes?
Could you run "htop" in a terminal so that you see which program is
blocking? It might be something spawned from kmail or something totally
different.
10:41 p.m.
On Wednesday 07 October 2020 17:27:29 William Morder via tde-users wrote:
On Wednesday 07 October 2020 13:55:23 Gene Heskett via
tde-users wrote:
But I've never grown up Bill. Wider at times but never up. My 3rd wife of
31 years if she makes it to Dec 2nd would be the first to confirm that.
She is in a rest home and has a bone infection from a broken hip
(replaced 3 years ago) thats gone septic and is very painful. But she
has said several times in the last 2 days that she has hurt long enough,
get it over with so they are not going to operate to try and clean it
up. So I may be alone before that 31st anniversary rolls around. That
will make 3 women I've outlived. The first gave me two girls and a boy,
in the decade before she had a stroke and died, all are gone now. I
still miss her. The 2nd gave me 3 more boys who've done well, And Dee
and I were both neutered long ago. So I've been alone for about 4 months
now. A man isn't supposed to outlive his kids but I seem to have the
nack.
Right now its day by day. I try to keep busy, but...
On Wednesday 07 October 2020 11:24:30 Michael via
tde-users wrote:
Hi, Gene!
I want to be just like you when I grow up.
Not horribly important, but whenever KMail checks
mail is
‘freezes’ for a bit and interrupts typing/mouse clicks (just for
KMail, rest of system runs fine).
Would it be hard to make KMail multi-threaded? I’m assuming
that’d ‘fix’ the freezes…
Again, not at all critical, but if it’s easy, I’ll get off my butt
and put in a feature request.
I was given to understand a decade back by Ingo Kloker that it was
going to be a major rewrite.
So I did the next best thing. using fetchmail I took that job away
from kmail by running as a daemon set to go get any email there
might be at my ISP's mail server, and configured it to use procmail
as the MTA. Then I learned to write recipes for procmail to get rid
of the worst of the spammers, the wrote more recipes to filter
incoming thru clamav, and ditto spamd so at least 75% of that crap
goes to /dev/null.
What survives that gauntlet gets dumped into /var/mail/name, and
another scrip has launched inotifywait to watch that buffer
location. Inotifywait exits with the name of the file and my script
then uses dbus to send kmail a get the mail command. And relaunches
inotifywait again. So the freeze is reduced to a few milliseconds
while it gets that incoming mail and sorts it to the correct folder.
Sounds a bit complex but it all Just Works. 2 mouse clicks to answer
a message as I am doing now. Whats not to like?
Cheers, Gene Heskett Bill
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinity
desktop.org
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>
11:03 p.m.
On Wednesday 07 October 2020 04:45:51 pm deloptes via tde-users wrote:
I think this is a use case specific issue and has
probably to do with the
number of filters. I am not sure how and where they are executed, but it
sounds like the GUI is blocked until something executes in the background.
I would not say it is related to the retrieving of the mails as a process
but most probably in something after the message is already there.
You could use tcpdump and wireshark to see the timeline for example.
You probably don't have the debug package installed, but if it is there you
could enable debugging for kmail and some tdeio like pop3 or imap etc.
Restart kmail and see what the log says.
I don't have any better idea for now.
We've most likely spent more time than this is worth already, and like you my
best guess is number of messages combined with number of filters.
BTW it's also not clear which protocol you use -
POP/IMAP?
POP through an always present SSH tunnel.
I was given to understand a decade back by Ingo Kloker
that it was going
to be a major rewrite.
And that’s good enough for me to lay this to rest.
Sounds a bit complex but it all Just Works. 2 mouse
clicks to answer a
message as I am doing now. Whats not to like?
Did you ever do a write up somewhere? I can’t just delete mail (have to have
15 day retention on pretty much everything) but I’ve used most of the tools
you talk about, so I’d like to play with it so to speak.
Thanks All,
Michael
11:48 p.m.
On Wednesday 07 October 2020 19:03:04 Michael via tde-users wrote:
Not recent enough to be valid today. Some new spammer shows up and he
soon gets added to the procmail filters, so lets just say its semi
dynamic. I don't retain that stuff more than 48 hours max as its fed to
sa-learn about 1 every morning, moved to a save dir in case a mistake
was made, and if I don't move it from that dir in that 24 hours, the
same script throws it away before copying in the new saved listings. So
spam gets fed to sa-learn and saved, and if I don't move it, its gone
the next day. If its spam, why should I waste time and disk storing it
for 2 weeks?
Some lists I'm on are saved forever and I do have archives back to 2002
of some lists, but many have a 60 day expiry, or less.
On Wednesday 07 October 2020 04:45:51 pm deloptes via
tde-users wrote:
Just as well. there are several other ways to attack that problem,
fetchmail/procmail was the obvious tool at the time it got under my
skin, about 15 years ago now.
I think this is a use case specific issue and has
probably to do
with the number of filters. I am not sure how and where they are
executed, but it sounds like the GUI is blocked until something
executes in the background. I would not say it is related to the
retrieving of the mails as a process but most probably in something
after the message is already there. You could use tcpdump and
wireshark to see the timeline for example.
You probably don't have the debug package installed, but if it is
there you could enable debugging for kmail and some tdeio like pop3
or imap etc. Restart kmail and see what the log says.
I don't have any better idea for now.
We've most likely spent more time than this is worth already, and like
you my best guess is number of messages combined with number of
filters.
BTW it's also not clear which protocol you
use - POP/IMAP?
POP through an always present SSH tunnel.
I was given to understand a decade back by Ingo
Kloker that it was
going to be a major rewrite.
And that’s good enough for me to lay this to rest. Sounds a bit
complex but it all Just Works. 2 mouse clicks to answer
a message as I am doing now. Whats not to like?
Did you ever do a write up somewhere? I can’t just delete mail (have
to have 15 day retention on pretty much everything) but I’ve used most
of the tools you talk about, so I’d like to play with it so to speak.
Thanks All,
Michael
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinity
desktop.org
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>
8 Oct
8 Oct
10:19 a.m.
It's quite hard making threads when you are spamming but once you start creating
unique content, it becomes very easy for you to publish your content by
https://bestseo.com.pk/content-writing-service
1309
days inactive
1310
days old
11 comments
6 participants
participants (6)
-
deloptes -
Dr. Nikolaus Klepp -
Gene Heskett -
Michael -
ridahashmi9211＠gmail.com -
William Morder