We had this this morning: Oct 25 12:36:34 msslat dovecot: imap(keh2): Error: user keh2: Initialization failed: Namespace '#mbox/': mkdir(/stage/mail/imap1/keh2/mail) failed: Permission denied (euid=2291(keh2) egid=101(luci) missing +w perm: /stage/mail/imap1, euid is not dir owner) Oct 25 12:36:34 msslat dovecot: imap(keh2): Error: Invalid user settings. Refer to server log for more information. Oct 25 12:36:35 msslat dovecot: imap-login: Login: user=<keh2>, method=PLAIN, rip=128.40.73.160, lip=128.40.73.13, mpid=26736 Oct 25 12:36:35 msslat dovecot: imap(keh2): Error: user keh2: Initialization failed: Namespace '#mbox/': mkdir(/stage/mail/imap1/keh2/mail) failed: Permission denied (euid=2291(keh2) egid=101(luci) missing +w perm: /stage/mail/imap1, euid is not dir owner) Oct 25 12:36:35 msslat dovecot: imap(keh2): Error: Invalid user settings. Refer to server log for more information. Because the parent directory was rwxr-xr-x root.root The problem is that for some reason dovecot then wedged and a lot of other stuff piled up behind it, causing people to complain their mail wasn't coming through. Load average climbed to over 100. Creating the user directories freed things up...
On 2010-10-25 9:13 AM, Alan Brown wrote:> We had this this morning:2.0 is still getting a good number of bug fixes so if you're going to use it you should be prepared to upgrade to the latest and see if the problem is already fixed before reporting a possible bug. 2.0.6 was just released... -- Best regards, Charles
> From: Charles Marcus <CMarcus at Media-Brokers.com> > On 2010-10-25 9:13AM, Alan Brown wrote:> > > We had this this morning: > 2.0 is still getting a good number of bug fixes so if you're going to > use it you should be prepared to upgrade to the latest and see if the > problem is already fixed before reporting a possible bug.I have been, but I've seen no similar reports and it may still be in 2.0.6. I will update to that version during a planned maintenance window tomorrow.
On 25.10.2010, at 14.13, Alan Brown wrote:> Oct 25 12:36:34 msslat dovecot: imap(keh2): Error: user keh2: Initialization failed: Namespace '#mbox/': mkdir(/stage/mail/imap1/keh2/mail) failed: Permission denied (euid=2291(keh2) egid=101(luci) missing +w perm: /stage/mail/imap1, euid is not dir owner) > > Because the parent directory was rwxr-xr-x root.rootRight..> The problem is that for some reason dovecot then wedged and a lot of other stuff piled up behind it, causing people to complain their mail wasn't coming through. Load average climbed to over 100. > > Creating the user directories freed things up...So the problem is that if there's a misconfiguration, load goes up? I don't really know if there's much to do about this. I guess it could wait a second or so before disconnecting client to avoid it reconnecting back too fast..
> From: Timo Sirainen <tss at iki.fi> > Subject: Re: [Dovecot] 2.0.3 Bug - hanging issue > > On 25.10.2010, at 14.13, Alan Brown wrote: > >> > Oct 25 12:36:34 msslat dovecot: imap(keh2): Error: user keh2: Initialization failed: Namespace '#mbox/': mkdir(/stage/mail/imap1/keh2/mail) failed: Permission denied (euid=2291(keh2) egid=101(luci) missing +w perm: /stage/mail/imap1, euid is not dir owner) >> > >> > Because the parent directory was rwxr-xr-x root.root > Right.. > >> > The problem is that for some reason dovecot then wedged and a lot of other stuff piled up behind it, causing people to complain their mail wasn't coming through. Load average climbed to over 100. >> > >> > Creating the user directories freed things up... > So the problem is that if there's a misconfiguration, load goes up? I don't really know if there's much to do about this. I guess it could wait a second or so before disconnecting client to avoid it reconnecting back too fast.. >The client wasn't reconnecting as far as I can tell. It looked to me like the server process wedged after this error - we only got the error message logged once. The problem is that after it occurred no new clients could complete connections, but existing clients worked ok. Incoming connections were accepted, but then nothing would happen. As far as I can tell the parent would fork new child processes but they couldn't complete initialisation. Mail clients simply complained of a timeout during connection. This was affecting all users. With regard to error disconnections - yes a delay is a good idea.