Hi all,
I've run into an issue we have with dovecot versions 2.0.12 through 2.0.14 on
latest CentOS 6.2 when dealing with Maildirs located on NFS partitions.
Although I saw Mr. Egbert's thread, his resolution does not work on our
end.
When dealing with users with over 500 messages in any of their Maildir
folders, they occasionally receive an error from the server:
Internal error occurred. Refer to server log for more information.
The corresponding log entries:
dovecot: imap(user1): Error: readdir(/u1/user1/Maildir/.AUTO-DELETED-SPAM/new)
failed: Too many levels of symbolic links
dovecot: imap(user1): Error: readdir(/u1/user1/Maildir/.logwatch/new) failed:
Too many levels of symbolic links
dovecot: imap(user2): Error: readdir(/u2/user2/Maildir/cur) failed: Too many
levels of symbolic links
dovecot: imap(user2): Error: readdir(/u2/user2/Maildir/.Trash/new) failed: Too
many levels of symbolic links
dovecot: imap(user3): Error: readdir(/u1/user3/Maildir/.Trash/new) failed: Too
many levels of symbolic links
dovecot: imap(user3): Error: readdir(/u4/user3/Maildir/.AUTO-DELETED-SPAM/new)
failed: Too many levels of symbolic links
dovecot: imap(user4): Error: readdir(/u1/user4/Maildir/.AUTO-DELETED-SPAM/new)
failed: Too many levels of symbolic links
dovecot: imap(user4): Error: readdir(/u1/user4/Maildir/new) failed: Too many
levels of symbolic links
A 'find . -type l' shows there are absolutely no symbolic links to be
found in those directories.
Running readdir.c that Timo provided always returns errno == 0 on {cur,new} of
all the directories reported in the logs.
It does not occur consistently in production, but it does tend to occur
to a fuzzy set of the same users on different partitions. We can
replicate it every time in testing.
The file count in these directories are all over the place, from less than a
thousand to multiple thousands. However, it's hard to calculate what may
have been in new prior to the clients processing/sorting that mail. It
may have been more on the higher side than lower.
The error tends to favor new over cur, but there are exceptions.
The tests we have been trying:
Create a new folder using alpine, save anywhere from 1000 to 1 identical
emails to the new folder.
Change to that new folder, thus prompting the move from new to cur. The client
receives the message and aborts the opening. Anywhere from 400-520 files are
successfully moved each time. It takes numerous attempts to finally move
all the files over--which I suspect some IMAP clients do, hence the
inconsistent errors in production.
We then create a brand new folder with the same amount of files and
verify that the error is reproduceable--which it is.
I'm leaning towards some sort of bug on the NFS client level, as Timo
mentioned, but the odd thing is we were running this setup since early
April and did not begin seeing these errors until early May--with user
load being relatively consistent during that time. I would think the bug
would have been evident before then. I'm also curious as to why dovecot
is getting an ELOOP error code from it.
Any ideas or pointers would be appreciated, sorry for the length. :)
--
Tom Pawlowski
OIT-CSS System Administrator office: Hill 145
email: tom...@jla.rutgers.edu phone: (732) 445-2634
