Two times this evening I have lost an email I just typed when I clicked on send: The windwo became grey and unresponsive Closing the window gives you a dialog asking if you want to save an "entwurf" in german ( I am just missing the word in english shame on me.) The saving as "entwuf" does not work, also I loose the email I suggest, 1) Fixing this one bug (grey windwow) 2) Changing the way it all works: As soon as you create a new mail, it should autosave it as entwurf (lets say every 30 secondes if something change or every minute if something change) Thanks this, it would be less likely to completely loose your email if such a bug re-occur Outlook is working like that tell me what you think about that, I will rais a wish in the wishlist. Reproducible: Sometimes
"1) Fixing this one bug (grey windwow) " we need more infos about it. Because I can't fix it just because you told that it's grey "2)" it's already autosave
Created attachment 71242 [details] The screen just after clicking on send This is the "grey" screen just after you click on send, you can wait hours nothing will appear ( no Knotify saying "Email successfully sent" ) and this one window won't disappear Which bring us to the next attachement
Created attachment 71243 [details] Once you click the cross You try to close the window, to see what happend and you land with this one dialog box You then click "Als Entwurf speichern" something like save as draft. And you then expect the email to be save as draft and the window to get closed . This however bring us to the two next attachement
Created attachment 71244 [details] Once the dialob box get closed this is what appear once the previsouly displayed dialog box get closed . also this time you might want to click the red cross and click "verwerfen" or eventually skill -9 kontact
Created attachment 71245 [details] And once you go to "Entwurfe" folder And saddly there is no email saved as draft in your Entwurfe Folder. ( as you can see when comparing the subject field, the one email that you will see in the Entwurfe (Draft) Folder is anoter email..
1) -> Whats more info do you need ( since 12.04 it happens with almost every emails ) 2) No it does not, not at all, the proof in image. What I would wish is 1) Each email get automatically saved as draft as soon as it is created ( i,e like in Outlook|) 2) That it is autosaved ecvery minute or every variable amount of time, defined by the
It started to happen with update to KDE 4.8.0, unfortunatelly this bug is quite random and I cannot find any relation to events like network connection loss etc... My setup is 3 accounts - 2x pop3/smtp with drafts/templates stored in local folder - 1x imap/smtp with all folders on the imap server Sometimes sendng new email or manually save it as draft/template fails, composer window greys-out and freezes. If you won't close window and wait several minutes mail will be eventually send/saved. But the time you have to wait is extremely random, it might be 30s up to 40 minutes. Sometimes it also causes main kmail window to freeze too. Restarting KMail+Akonadi+Nepomuk or even logout/logon usually won't solve the problem and full reboot is nessesary. Additional symptom is long time of retrieving mesages (+10 s.) THat happens even for mails stored locally. Similar delay occurs when I try to reply/forward mail. Pop-up window with "Please wait for mail forward" and progress-bar. Some errors appear in ~/.xsession-erros log wchich seems to be related: QDBusObjectPath: invalid path "" Query failed: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." QStringList Akonadi::NepomukSearch::search(const QString&) Calling blockingQuery() failed! Related software: ====================== akonadi-1.7.2-1.fc16.i686 kdepim-4.8.3-2.fc16.i686 kde-runtime-4.8.3-1.fc16.i686 Is there any more info I can provide to nail this bug? If you need any logs from system, akonadi-konsole plz let me know.
Additional note, top shows all the processes are idling, ie any of the nepomuk* ,akonadi* ,virtuoso* ,kontact ,postgresql* processes has cpu usage <1%. (I use postgresql as my akonadi db backend). Also it's unrelated to KDe wallet, i vtried to lock my screen, close open wallet and it wont affect my ability/unability to send mail.
I have the same problem here, sometimes - usually this bug occurs together with a very sluggish folder view in the Kmail2 part of Kontacts. It may be related to time-outs on the internet connection, because my connection is sometimes unreliable. (Not that the "sending" times out, but something else that was going on earlier.) When the Compose window is unresponsive (after you click "Send"), you can just wait until it does send... it takes a few minutes but happens eventually. I think the akonadi backend gets into some kind of locked state or race condition when some online action fails or times out or hangs (unrelated to the Compose or Send, but the same account). For example, related symptoms are: The folder view does not update automatically any longer, it takes a long time to mark messages as read, and if you try to forward or reply to a message, there will be a popup saying "Please wait while the message is being transferred", and it doesn't go away. By the way, I'm replying into this thread because the title describes exactly the same error/bug that I am experiencing. I think that, if you want to raise the second topic of this thread as a suggestion (the "autosave" feature for the composer window), this should be raised in a different bug. Potential duplicate of bug 301105 ?
I get the same error message as S.Trzmiel. Kmail hangs about 3 or 4 times a week, and the only reliable way of fixing the problem is a reboot. Sometimes it fixes itself but you have to wait a long time. I don't think this is a network problem because I send my mail from kmail to localhost, and I still get this hanging problem. For me: akonadi-1.7.2-1.fc16.x86_64 kdepim-4.8.4-4.fc16.x86_64 kde-runtime-4.8.4-2.fc16.x86_64
Setting status to confirmed.
Interestingly, the problem happened again today. The mail refused actually to send, so I rebooted after 90 minutes. After the reboot, when I then tried to send a second mail, it also refused to go. I then did "killall -9 akonadiserver" and the mail transmitted instantly. I'll try that again next time and let you know if it still works.
I have the same problem. when it starts is nearly impossible to use Kontact/KMail. I am thinking about migrating from Kmail to some other email client. Email is vital in our work today.
For me this comes together with a very slow reaction on changing the mail actually shown. It immediately dissapears if I disable nepomuk in systemsettings (sometimes only nepomuk for akonadi, sometimes all of nepomuk). Kontact has some irregularities afterwards but works well after restart. The slowness disappears immediately.
I had it happen again; I immediately ran "killall -9 akonadiserver" and the mail sent successfully. So on a sample of two, this seems to be a good workround. Of course, I then have to restart kmail to get everything back to normal, but it's better than waiting 45 minutes for the partially sent email to send.
The previous workrounds (kill -9 akonadiserver) have not worked for me for a while. However, I have a new workround which appears to be simpler and may give a hint as to the problem. It is to kill gam_server and all nepomuk processes. Kill them, and the mail sends instantly. (The processes restart afterwards.)
Thank you Maxime for your report and to all the commenters for comments. It is about a version of KMail which is currently unmaintained. Thus closing. I saw this issue myself with earlier versions of KMail and Akonadi, but didn´t see it in some time. If you still see it, try to find a pattern to reproduce it and open a new report. Also only report exactly one issue per report. Thank you and greetings from KDE Randa Meetings, Martin
Speaking for myself, after many years of wrestling with kmail/akonadi I have now switched to mutt on all my platforms, so absence of further reports from me should not be taken to indicate lack of bug.