Version: 2.1.0 (using KDE 4.6.3) OS: Linux When the KWallet is closed (for example by locking the session) and subsequently reopened by an application other than KMail, then sending mail in KMail hangs forever. The message sits in the Outbox and is never sent. This behavior actually occurred in KMail 1, too, but now that mail is passed through Akonadi, things are a bit different. In KMail 1, if I tried to quit KMail while it was in this state, the UI would close, but the kmail process would continue running, and I had to kill it with SIGTERM. Then relaunching KMail and choosing "Send Queued Messages" would get the mail to go out. Now, in KMail 2, I can quit KMail and the process actually terminates, but when I relaunch, the mail is still sitting in the Outbox. The way to unstick it now seems to be to kill the Akonadi Mail Dispatcher process. The Akonadi server immediately relaunches that agent, and the mail sends. Reproducible: Always Steps to Reproduce: 1. Have KMail open. 2. Close the wallet. 3. Access the wallet from another application to cause it to prompt for the password and be reopened. 4. Try to send a message in KMail. Actual Results: Message sits in Outbox forever, and there is no attempt to connect to the SMTP server. Killing the Akonadi Mail Dispatcher (thereby restarting it) causes the message to be sent. Expected Results: If the wallet is already open (even if it was reopened by another application after having been closed), the Mail Dispatcher should have no problem establishing a connection to the SMTP server.
similar issue here, and it could be related to kwallet (usually my kmail has the permissions to access the wallet) mails stay in the outbox forever until i killall akonadi_maildispatcher_agent
I can confirm for kmail 2.
(In reply to comment #2) > I can confirm for kmail 2. Likewise. Also, if I open up Akonadi Console and restart the Mail Dispatcher Agent, my messages go right out immediately.
For me a restart doesn't do it, because it was switched offline even after that, I had to toggle it online in the Akonadi console.
I have had a similar problem, see bug report 284703. I had the impression that it was related to kwallet, suspending the machine or a combination. Sounds like you are closer to explain how to provoke the bug.. I am not marking it as a duplicate yet. I leave that for the experts to decide. I had the issue twice this week. When it happens the "send queued messages" disappear as an option when right clicking the outbox folder, so I guess kmail somehow believe the outbox is empty..
Haven't seen this bug for a long time, for me it's fixed.
I still get this all the time on KDE 4.8.4. I have to open the Akonadi Console and restart the Mail Dispatcher Agent to get mail outgoing mail to send. It sure seems like the Mail Dispatcher Agent is waiting for wallet authentication, but the wallet has not popped up the password dialog because the wallet is already (re)opened.
@Cyril I think this is one of those bugs that depend on how you have things configured (e.g. when KWallet should close), so I would be careful about assuming this is fixed based on not having seen it for a while..
I'm seeing this hang right now. I have a message sitting in my Outbox in KMail. KMail is responsive. Akonadi is running. Akonadi Console says the "Mail Dispatcher Agent" is "Ready to dispatch messages." I can click "Send Queued Messages" in the File menu of KMail, and nothing happens. If I attach to the akonadi_maildispatcher_agent process in gdb, I can see that it has one thread, which is parked in its event loop, waiting for events to come in: #0 0x00007ffe7e7c6078 in *__GI___poll (fds=0x1b75ad0, nfds=5, timeout=2390494) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00007ffe7d036cf5 in g_main_context_poll (n_fds=5, fds=0x1b75ad0, timeout=2390494, context=0x1aa0130, priority=<optimized out>) at gmain.c:3440 #2 g_main_context_iterate (context=0x1aa0130, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3141 #3 0x00007ffe7d036e65 in g_main_context_iterate (dispatch=1, block=1, context=0x1aa0130, self=<optimized out>) at gmain.c:3113 #4 g_main_context_iteration (context=0x1aa0130, may_block=1) at gmain.c:3207 #5 0x00007ffe815cee3f in QEventDispatcherGlib::processEvents (this=0x1a7a740, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #6 0x00007ffe7f22442e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #7 0x00007ffe8159ea42 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #8 0x00007ffe8159ecf5 in QEventLoop::exec (this=0x7fffb9c72a00, flags=...) at kernel/qeventloop.cpp:204 #9 0x00007ffe815a374b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187 #10 0x00007ffe81bda736 in Akonadi::AgentBase::init (r=0x1c80110) at /var/tmp/portage/kde-base/kdepimlibs-4.8.4/work/kdepimlibs-4.8.4/akonadi/agentbase.cpp:564 #11 0x000000000040d590 in Akonadi::AgentBase::init<MailDispatcherAgent> (argc=<optimized out>, argv=<optimized out>) at /usr/include/KDE/Akonadi/../../akonadi/agentbase.h:342 #12 0x00007ffe7e7064bd in __libc_start_main (main=0x40a130 <main(int, char**)>, argc=3, ubp_av=0x7fffb9c72c88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb9c72c78) at libc-start.c:226 #13 0x000000000040a1f5 in _start () If I attach to the "kdeinit4: kwalletd" process, I can see that it, too, has one thread, which is parked in its event loop: #0 0x00007f542abda078 in *__GI___poll (fds=0x131be60, nfds=6, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00007f5427896cf5 in g_main_context_poll (n_fds=6, fds=0x131be60, timeout=-1, context=0x119c210, priority=<optimized out>) at gmain.c:3440 #2 g_main_context_iterate (context=0x119c210, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3141 #3 0x00007f5427896e65 in g_main_context_iterate (dispatch=1, block=1, context=0x119c210, self=<optimized out>) at gmain.c:3113 #4 g_main_context_iteration (context=0x119c210, may_block=1) at gmain.c:3207 #5 0x00007f542c22de3f in QEventDispatcherGlib::processEvents (this=0x11a6950, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #6 0x00007f542b42242e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #7 0x00007f542c1fda42 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #8 0x00007f542c1fdcf5 in QEventLoop::exec (this=0x7fff6b7fef90, flags=...) at kernel/qeventloop.cpp:204 #9 0x00007f542c20274b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187 #10 0x00007f541a89505f in kdemain (argc=1, argv=0x114a660) at /var/tmp/portage/kde-base/kwalletd-4.8.4/work/kwalletd-4.8.4/kwalletd/main.cpp:68 #11 0x0000000000409084 in launch (argc=<optimized out>, _name=0x1157658 "/usr/bin/kwalletd", args=<optimized out>, cwd=0x0, envc=<optimized out>, envs=<optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x1157685 "Crushinator;1343434237;514746;4479_TIME0") at /var/tmp/portage/kde-base/kdelibs-4.8.4-r1/work/kdelibs-4.8.4/kinit/kinit.cpp:734 #12 0x000000000040a376 in handle_launcher_request (sock=7, who=<optimized out>) at /var/tmp/portage/kde-base/kdelibs-4.8.4-r1/work/kdelibs-4.8.4/kinit/kinit.cpp:1226 #13 0x000000000040a8b3 in handle_requests (waitForPid=0) at /var/tmp/portage/kde-base/kdelibs-4.8.4-r1/work/kdelibs-4.8.4/kinit/kinit.cpp:1419 #14 0x0000000000405a9e in main (argc=2, argv=0x7fff6b800040, envp=0x7fff6b800310) at /var/tmp/portage/kde-base/kdelibs-4.8.4-r1/work/kdelibs-4.8.4/kinit/kinit.cpp:1907 CPU usage is minimal. Perhaps it's a stand-off? When I right-clicked on "Mail Dispatcher Agent" in the Akonadi Console and chose "Restart Agent," it immediately sent the message that had been waiting in my Outbox.
*** Bug 284703 has been marked as a duplicate of this bug. ***
After starting to use Telepathy, which opens the wallet quite often, this problem is close to a showstopper to me. Having e-mails not sent all the time is quite frustrating! I just had the problem again for the 10th time in the last week (approximate), and when I selected to restart the mail dispatcher agent, kwallet immediately asked for my password and then the e-mail was sent.
setting status and version correctly, raising bug importance.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.