[Dovecot] 2.0 migration weirdnesses: logs and hang
Hello,
I'm testing out an upgrade to dovecot 2.0 from 1.2.11, and I've stumbled across two weirdnesses that I need help with.
First, I'm only getting one log message:
master: Info: Dovecot v2.0.0 starting upAfter that, while I can connect, log in, read mail, etc., no further log messages are created.
I have log_path set to /dev/stderr, and no syslog_facility setting, so... what could be going wrong?
Second, when I create a new mailbox and copy messages across namespaces, dovecot hangs. The mailbox is created and the messages are copied successfully, but dovecot simply stops responding. I can't even logout!
I'm attaching my config file, if it helps.
~Kyle
The effect of liberty to individuals is, that they may do what they please; we ought to see what it will please them to do, before we risk congratulations. -- Edmund Burke
On Thu, 2010-08-19 at 12:59 -0500, Kyle Wheeler wrote:
After that, while I can connect, log in, read mail, etc., no further log messages are created.
I have log_path set to /dev/stderr, and no syslog_facility setting, so... what could be going wrong?
I've never tried logging to /dev/stderr with v2.0. I guess it should be possible to fix it..
Second, when I create a new mailbox and copy messages across namespaces, dovecot hangs. The mailbox is created and the messages are copied successfully, but dovecot simply stops responding. I can't even logout!
So you can easily reproduce this? Could you get gdb backtrace from the hanging process?
gdb -p <pid of hanging imap process> bt full
On Thursday, August 19 at 07:05 PM, quoth Timo Sirainen:
I have log_path set to /dev/stderr, and no syslog_facility setting, so... what could be going wrong?
I've never tried logging to /dev/stderr with v2.0. I guess it should be possible to fix it..
:)
Second, when I create a new mailbox and copy messages across namespaces, dovecot hangs. The mailbox is created and the messages are copied successfully, but dovecot simply stops responding. I can't even logout!
So you can easily reproduce this? Could you get gdb backtrace from the hanging process?
gdb -p <pid of hanging imap process> bt full
Sure thing. By the way, the proctitle is
dovecot/imap [kyle@memoryhole.net 64.253.106.173 CLOSE UID COPY]Here's the backtrace:
#0 0xb7fab424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7defff8 in epoll_wait () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb7ec51f9 in io_loop_handler_run (ioloop=0x806d360) at ioloop-epoll.c:179
ctx = (struct ioloop_handler_context *) 0x806d480
event = <value optimized out>
list = <value optimized out>
io = <value optimized out>
tv = {tv_sec = 1794, tv_usec = 888651}
t_id = <value optimized out>
msecs = 1794889
ret = 0
i = <value optimized out>
j = <value optimized out>
call = <value optimized out>
#3 0xb7ec4250 in io_loop_run (ioloop=0x806d360) at ioloop.c:350
No locals.
#4 0xb7eb172a in master_service_run (service=0x806d2b0, callback=0x8060040
I can recompile without optimization, if that would help (I just used the default -O2).
~Kyle
The future is here. It's just not widely distributed yet. -- William Gibson
On Thu, 2010-08-19 at 13:12 -0500, Kyle Wheeler wrote:
Second, when I create a new mailbox and copy messages across namespaces, dovecot hangs. The mailbox is created and the messages are copied successfully, but dovecot simply stops responding. I can't even logout!
Did you try this with IMAP client or via talking IMAP directly? Is it really relevant that it's being done across namespaces? If it seems to be, try also within a namespace but with maildir_copy_with_hardlinks=no? What namespaces did you create?
dovecot/imap [kyle@memoryhole.net 64.253.106.173 CLOSE UID COPY]
So UID COPY hasn't finished. Probably also relevant that CLOSE was pipelined.
Here's the backtrace:
#0 0xb7fab424 in __kernel_vsyscall () No symbol table info available. #1 0xb7defff8 in epoll_wait () from /lib/i686/cmov/libc.so.6 No symbol table info available.
So it's not hanging. It's just waiting for something..
On Friday, August 20 at 07:58 PM, quoth Timo Sirainen:
Did you try this with IMAP client or via talking IMAP directly?
I did it with mutt as my IMAP client. I'm attaching a log of the IMAP conversation. The log ends at the point that I had to kill mutt to regain control. It looks like mutt is stuck waiting for Dovecot to reply "a0049 OK Idle completed."
Is it really relevant that it's being done across namespaces?
I just tried it within the same namespace: no, it's not relevant.
If it seems to be, try also within a namespace but with maildir_copy_with_hardlinks=no?
I just tried it with maildir_copy_with_hardlinks=no; I got the exact same behavior.
~Kyle
To invent, you need a good imagination and a pile of junk. -- Thomas Jefferson
On 20.8.2010, at 22.20, Kyle Wheeler wrote:
On Friday, August 20 at 07:58 PM, quoth Timo Sirainen:
Did you try this with IMAP client or via talking IMAP directly?
I did it with mutt as my IMAP client. I'm attaching a log of the IMAP conversation. The log ends at the point that I had to kill mutt to regain control. It looks like mutt is stuck waiting for Dovecot to reply "a0049 OK Idle completed."
In that trace Dovecot has sent reply to everything mutt has asked for. Although it looks like mutt has skipped logging some of the commands it has sent (LIST commands, e.g. a0002 or a0042). Perhaps it sent something else that Dovecot didn't reply to yet? .. Get a log with Dovecot's rawlog: http://wiki2.dovecot.org/Debugging/Rawlog
On Friday, August 20 at 10:25 PM, quoth Timo Sirainen:
On 20.8.2010, at 22.20, Kyle Wheeler wrote:
On Friday, August 20 at 07:58 PM, quoth Timo Sirainen:
Did you try this with IMAP client or via talking IMAP directly?
I did it with mutt as my IMAP client. I'm attaching a log of the IMAP conversation. The log ends at the point that I had to kill mutt to regain control. It looks like mutt is stuck waiting for Dovecot to reply "a0049 OK Idle completed."
In that trace Dovecot has sent reply to everything mutt has asked for. Although it looks like mutt has skipped logging some of the commands it has sent (LIST commands, e.g. a0002 or a0042). Perhaps it sent something else that Dovecot didn't reply to yet? .. Get a log with Dovecot's rawlog: http://wiki2.dovecot.org/Debugging/Rawlog
I'm attaching the output of the rawlog.
~Kyle
No people can be great who have ceased to be virtuous. -- Samuel Johnson, on the behavior of the British colonists in America
On 23.8.2010, at 23.37, Kyle Wheeler wrote:
In that trace Dovecot has sent reply to everything mutt has asked for. Although it looks like mutt has skipped logging some of the commands it has sent (LIST commands, e.g. a0002 or a0042). Perhaps it sent something else that Dovecot didn't reply to yet? .. Get a log with Dovecot's rawlog: http://wiki2.dovecot.org/Debugging/Rawlog
I'm attaching the output of the rawlog.
Could you do once more with -bt options?
On Tuesday, August 24 at 12:17 AM, quoth Timo Sirainen:
On 23.8.2010, at 23.37, Kyle Wheeler wrote:
In that trace Dovecot has sent reply to everything mutt has asked for. Although it looks like mutt has skipped logging some of the commands it has sent (LIST commands, e.g. a0002 or a0042). Perhaps it sent something else that Dovecot didn't reply to yet? .. Get a log with Dovecot's rawlog: http://wiki2.dovecot.org/Debugging/Rawlog
I'm attaching the output of the rawlog.
Could you do once more with -bt options?
Attached. It looks like the rest of the commands in the same packet after mutt told Dovecot that it was "DONE" with IDLE were ignored.
~Kyle
When did 'There but for the grace of God, go I' get replaced with 'It sucks to be you'? And what can you and I do about it? -- Billy Payne
On Wednesday, August 25 at 03:34 PM, quoth Kyle Wheeler:
On Tuesday, August 24 at 12:17 AM, quoth Timo Sirainen:
On 23.8.2010, at 23.37, Kyle Wheeler wrote:
In that trace Dovecot has sent reply to everything mutt has asked for. Although it looks like mutt has skipped logging some of the commands it has sent (LIST commands, e.g. a0002 or a0042). Perhaps it sent something else that Dovecot didn't reply to yet? .. Get a log with Dovecot's rawlog: http://wiki2.dovecot.org/Debugging/Rawlog
I'm attaching the output of the rawlog.
Could you do once more with -bt options?
Attached. It looks like the rest of the commands in the same packet after mutt told Dovecot that it was "DONE" with IDLE were ignored.
Has this been dropped?
~Kyle
Every American expects and deserves clean air, and then we act on that belief, then we will set an example for the rest of the world to follow. -- George H. W. Bush
On Wed, 2010-08-25 at 15:34 -0500, Kyle Wheeler wrote:
Attached. It looks like the rest of the commands in the same packet after mutt told Dovecot that it was "DONE" with IDLE were ignored.
Hmh. I can't seem to find anything wrong with the code. I also tried mutt (1.5.20-7ubuntu1) with imap_idle enabled and didn't manage to break it.
I did fix a couple of bugs though, but I don't think those fix this hang: http://hg.dovecot.org/dovecot-2.0/rev/4d9768fd1a55 http://hg.dovecot.org/dovecot-2.0/rev/c7b351d415d9
On Wednesday, September 1 at 06:08 PM, quoth Timo Sirainen:
On Wed, 2010-08-25 at 15:34 -0500, Kyle Wheeler wrote:
Attached. It looks like the rest of the commands in the same packet after mutt told Dovecot that it was "DONE" with IDLE were ignored.
Hmh. I can't seem to find anything wrong with the code. I also tried mutt (1.5.20-7ubuntu1) with imap_idle enabled and didn't manage to break it.
I did fix a couple of bugs though, but I don't think those fix this hang: http://hg.dovecot.org/dovecot-2.0/rev/4d9768fd1a55 http://hg.dovecot.org/dovecot-2.0/rev/c7b351d415d9
Yeah, you're right, they don't fix this hang.
Were you at least able to duplicate the problem by playing back a similar series of commands? Is there anything else I can do to help isolate the problem?
~Kyle
It is precisely because it is fashionable for Americans to know no science, even though they may be well educated otherwise, that they so easily fall prey to nonsense. -- Isaac Asimov
On Thu, 2010-08-19 at 13:12 -0500, Kyle Wheeler wrote:
On Thursday, August 19 at 07:05 PM, quoth Timo Sirainen:
I have log_path set to /dev/stderr, and no syslog_facility setting, so... what could be going wrong?
I've never tried logging to /dev/stderr with v2.0. I guess it should be possible to fix it..
:)
On Friday, August 20 at 08:13 PM, quoth Timo Sirainen:
On Thu, 2010-08-19 at 13:12 -0500, Kyle Wheeler wrote:
On Thursday, August 19 at 07:05 PM, quoth Timo Sirainen:
I have log_path set to /dev/stderr, and no syslog_facility setting, so... what could be going wrong?
I've never tried logging to /dev/stderr with v2.0. I guess it should be possible to fix it..
:)
Thanks! Works like a charm.
~Kyle
When the people fear the government, there is tyranny; when the government fears the people, there is liberty. -- Thomas Jefferson
participants (2)
-
Kyle Wheeler
-
Timo Sirainen