in the last 6-8 months I have been having occasional failure of mail check both interval and manual.
The symptom is the bottom right progress bar shows constant movement with no percentage given and no new mail.Workaround is close kmail, reopen it go to Settings - Configure Mail - Accounts - Receiving - Modify - Apply (without editing anything) - OK and it downloads and will do so for 1~30 days and the same thing happens again.
Doesn't matter which of 4 POP3 accounts I select to (not) modify - all then download
Just open/close does not fix it nor TDE exit/new session or reboot. Machine normally runs 24/7
Has persisted through a complete machine replacement (with the same ~.trinity/share/apps/kmail/mail directory and filters
This is with KMail 1.9.10 (enterprise35.0.20100827.1168748) (Using Trinity 3.5.13.2) on Debian 7 reported by synaptic as kmail-trinity 4.3.5.13.2-0debiian7.0.0+0. The same setup had been working fine for some months beforehand
Any ideas ?
Regards
John Campbell
Am Montag, 10. November 2014 schrieb John Campbell:
in the last 6-8 months I have been having occasional failure of mail check both interval and manual.
The symptom is the bottom right progress bar shows constant movement with no percentage given and no new mail.Workaround is close kmail, reopen it go to Settings - Configure Mail - Accounts - Receiving - Modify - Apply (without editing anything) - OK and it downloads and will do so for 1~30 days and the same thing happens again.
Doesn't matter which of 4 POP3 accounts I select to (not) modify - all then download
Just open/close does not fix it nor TDE exit/new session or reboot. Machine normally runs 24/7
Has persisted through a complete machine replacement (with the same ~.trinity/share/apps/kmail/mail directory and filters
This is with KMail 1.9.10 (enterprise35.0.20100827.1168748) (Using Trinity 3.5.13.2) on Debian 7 reported by synaptic as kmail-trinity 4.3.5.13.2-0debiian7.0.0+0. The same setup had been working fine for some months beforehand
Any ideas ?
Regards
John Campbell
I had the same issue. It turned out that my ISP changed encryption. The "Check capabilities" returns TSL, but in fact it used SSL. Till I figured that out I had fetchmal pick up my mails, i.e. start fetchmail when kamil starts and stpr fetchmail when kmail stops.
Nik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
in the last 6-8 months I have been having occasional failure of mail check both interval and manual.
The symptom is the bottom right progress bar shows constant movement with no percentage given and no new mail.Workaround is close kmail, reopen it go to Settings - Configure Mail - Accounts - Receiving - Modify - Apply (without editing anything) - OK and it downloads and will do so for 1~30 days and the same thing happens again.
Doesn't matter which of 4 POP3 accounts I select to (not) modify - all then download
Just open/close does not fix it nor TDE exit/new session or reboot. Machine normally runs 24/7
Has persisted through a complete machine replacement (with the same ~.trinity/share/apps/kmail/mail directory and filters
This is with KMail 1.9.10 (enterprise35.0.20100827.1168748) (Using Trinity 3.5.13.2) on Debian 7 reported by synaptic as kmail-trinity 4.3.5.13.2-0debiian7.0.0+0. The same setup had been working fine for some months beforehand
Any ideas ?
Regards
John Campbell
I could get a much better idea of what is going on if, while KMail is stuck, you gather a backtrace and post it to the list.
First, install the tdepim debugging symbols and gdb (sudo apt-get install tdepim-trinity-dbg dbg). Then try to get KMail to hang (apparently this could take a while from what you describe). When kmail hangs do this: 1. )Open a terminal 2.) sudo gdb --pid `pidof kmail` 3.) thread apply all bt <post output to the list> 4.) q 5.) Close terminal, execute temporary workaround you described above
Thanks!
Tim
Will give that a try also fiddle with encryption in vm's
Regards
John Campbell
On Tue, 11 Nov 2014 03:17:24 Timothy Pearson wrote:
in the last 6-8 months I have been having occasional failure of mail check both interval and manual.
The symptom is the bottom right progress bar shows constant movement with no percentage given and no new mail.Workaround is close kmail, reopen it go to Settings - Configure Mail - Accounts - Receiving - Modify - Apply (without editing anything) - OK and it downloads and will do so for 1~30 days and the same thing happens again.
Doesn't matter which of 4 POP3 accounts I select to (not) modify - all then download
Just open/close does not fix it nor TDE exit/new session or reboot. Machine normally runs 24/7
Has persisted through a complete machine replacement (with the same ~.trinity/share/apps/kmail/mail directory and filters
This is with KMail 1.9.10 (enterprise35.0.20100827.1168748) (Using Trinity 3.5.13.2) on Debian 7 reported by synaptic as kmail-trinity 4.3.5.13.2-0debiian7.0.0+0. The same setup had been working fine for some months beforehand
Any ideas ?
Regards
John Campbell
I could get a much better idea of what is going on if, while KMail is stuck, you gather a backtrace and post it to the list.
First, install the tdepim debugging symbols and gdb (sudo apt-get install tdepim-trinity-dbg dbg). Then try to get KMail to hang (apparently this could take a while from what you describe). When kmail hangs do this:
- )Open a terminal
2.) sudo gdb --pid `pidof kmail` 3.) thread apply all bt
<post output to the list> 4.) q 5.) Close terminal, execute temporary workaround you described above
Thanks!
Tim
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
On Tue, 11 Nov 2014 03:17:24 Timothy Pearson wrote:
in the last 6-8 months I have been having occasional failure of mail check both interval and manual.
The symptom is the bottom right progress bar shows constant movement with no percentage given and no new mail.Workaround is close kmail, reopen it go to Settings - Configure Mail - Accounts - Receiving - Modify - Apply (without editing anything) - OK and it downloads and will do so for 1~30 days and the same thing happens again.
Doesn't matter which of 4 POP3 accounts I select to (not) modify - all then download
Just open/close does not fix it nor TDE exit/new session or reboot. Machine normally runs 24/7
Has persisted through a complete machine replacement (with the same ~.trinity/share/apps/kmail/mail directory and filters
This is with KMail 1.9.10 (enterprise35.0.20100827.1168748) (Using Trinity 3.5.13.2) on Debian 7 reported by synaptic as kmail-trinity 4.3.5.13.2-0debiian7.0.0+0. The same setup had been working fine for some months beforehand
Any ideas ?
Regards
John Campbell
I could get a much better idea of what is going on if, while KMail is stuck, you gather a backtrace and post it to the list.
First, install the tdepim debugging symbols and gdb (sudo apt-get install tdepim-trinity-dbg dbg). Then try to get KMail to hang (apparently this could take a while from what you describe). When kmail hangs do this:
- )Open a terminal
2.) sudo gdb --pid `pidof kmail` 3.) thread apply all bt
<post output to the list> 4.) q 5.) Close terminal, execute temporary workaround you described above
Thanks!
Tim
Took a long time - nearly 3 months but had a repeat. The trace is:
(gdb) thread apply all bt
Thread 5 (Thread 0x7fe26586a700 (LWP 4105)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fe26b5c6640 in QWaitCondition::wait (this=0x33b8720, time=18446744073709551615) at tools/qwaitcondition_unix.cpp:245 #2 0x00007fe271dead59 in KPIM::ThreadWeaver::Weaver::applyForWork (this=0x33b8650, th=0x24dc740, previous=0x0) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:519 #3 0x00007fe271dea99f in KPIM::ThreadWeaver::Thread::run (this=0x24dc740) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:215 #4 0x00007fe26b37111a in QThreadInstance::start (_arg=0x33b87d8) at kernel/qthread_unix.cpp:122 #5 0x00007fe270541b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #6 0x00007fe268fc1e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x0000000000000000 in ?? ()
Thread 4 (Thread 0x7fe265069700 (LWP 4106)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fe26b5c6640 in QWaitCondition::wait (this=0x33b8720, time=18446744073709551615) at tools/qwaitcondition_unix.cpp:245 #2 0x00007fe271dead59 in KPIM::ThreadWeaver::Weaver::applyForWork (this=0x33b8650, th=0x24a96a0, previous=0x0) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:519 #3 0x00007fe271dea99f in KPIM::ThreadWeaver::Thread::run (this=0x24a96a0) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:215 #4 0x00007fe26b37111a in QThreadInstance::start (_arg=0x33b8a78) at kernel/qthread_unix.cpp:122 #5 0x00007fe270541b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #6 0x00007fe268fc1e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x0000000000000000 in ?? ()
Thread 3 (Thread 0x7fe264868700 (LWP 4107)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fe26b5c6640 in QWaitCondition::wait (this=0x33b8720, time=18446744073709551615) at tools/qwaitcondition_unix.cpp:245 ---Type <return> to continue, or q <return> to quit--- #2 0x00007fe271dead59 in KPIM::ThreadWeaver::Weaver::applyForWork (this=0x33b8650, th=0x33b6f10, previous=0x0) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:519 #3 0x00007fe271dea99f in KPIM::ThreadWeaver::Thread::run (this=0x33b6f10) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:215 #4 0x00007fe26b37111a in QThreadInstance::start (_arg=0x33b8c68) at kernel/qthread_unix.cpp:122 #5 0x00007fe270541b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #6 0x00007fe268fc1e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fe264067700 (LWP 4108)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fe26b5c6640 in QWaitCondition::wait (this=0x33b8720, time=18446744073709551615) at tools/qwaitcondition_unix.cpp:245 #2 0x00007fe271dead59 in KPIM::ThreadWeaver::Weaver::applyForWork (this=0x33b8650, th=0x33b7150, previous=0x0) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:519 #3 0x00007fe271dea99f in KPIM::ThreadWeaver::Thread::run (this=0x33b7150) at /build/buildd/kdepim-trinity-3.5.13.2/libkdepim/weaver.cpp:215 #4 0x00007fe26b37111a in QThreadInstance::start (_arg=0x33b8ed8) at kernel/qthread_unix.cpp:122 #5 0x00007fe270541b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #6 0x00007fe268fc1e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fe2730ce760 (LWP 3990)): #0 0x00007fe268fbb963 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007fe26b3326f9 in QEventLoop::processEvents (this=0x240f860, flags=<optimized out>) at kernel/qeventloop_x11.cpp:294 #2 0x00007fe26b388889 in QEventLoop::enterLoop (this=0x240f860) at kernel/qeventloop.cpp:201 #3 0x00007fe26b388812 in QEventLoop::exec (this=0x240f860) at kernel/qeventloop.cpp:148 #4 0x000000000040368d in main (argc=3, argv=0x7fff895659b8) at /build/buildd/kdepim-trinity-3.5.13.2/kmail/main.cpp:110 (gdb)
Regards
John Campbell
-
Dr. Nikolaus Klepp -
John Campbell -
Timothy Pearson