I just want to add that I'm seeing the same problem. I unfortunately had to restart the imap service before I could do any debugging since my users were not able to receive their mail and were freaking out. I had 780 imap processes (normally there should be under 100) and I was unable to establish any new connections. Max daemons was set for 150. There is usually a couriertls process associated with each imapd, but those were not there. The imapd processes were not zombies though, I'm not sure how that is supposed to work, I would have expected that they would become zombies when their parent process died/exited. I should have straced some of them, but I wasn't thinking :-( Sorry.
I'm not using any type of file sharing or unusual access to the mail directories. > Kristian Duus Østergaard writes: > >> Hi Berndt, >> I have seen the exact same symptoms and think I've finally found the >> cause of the problem. Once in a while netatalk creates an .AppleDouble >> file in my maildir. Courier tries to use this as mailfolder but as it >> does not have the proper structure the imapd process seems to hang >> forever and at the same time looses it's parent process. >> So for now deleting the .AppleDouble folder and killing all imapd >> processes with a parent process of 1 which was created by the user with >> the problem, seems to solve the problem. >> This is of course a workaround, and I think courier should fail a little >> more gracefully when it encounters bad directories. > > I agree. However I cannot reproduce your problem. Nothing really happens > after I manually create $HOME/Maildir/.AppleDouble file. The LIST "" > "INBOX.%" command does allege that "INBOX.AppleDouble" exists, but all the > IMAP commands I've tried to access that folder come back with a standard > error message, "NO Mailbox does not exist, or must be subscribed to". > > If you can find out more information as to what specific IMAP commands result > in the server hanging, in this situation, I'm sure it can be easily fixed. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- > http://p.sf.net/sfu/sprint-com-first_______________________________________________ > courier-users mailing list > [email protected] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
