Robert Peterson wrote:
I suspect you are right: The question marks in ls -l leads me to
believe there
might be a problem somewhere regarding the locking of the files. My
theory is this:
ls -l calls a kernel stat function to get file statistics. The stat
tries to acquire an internal
lock (glock), but can't, so it displays what you see instead of valid
values.
Perhaps courier imap is locking files, then hanging, and the process
is somehow
hanging around with the lock intact, or else killed abnormally where
the lock is not released.
Do you have any suggestions how we can recreate this problem in our lab?
Robert, here is the scenario: we have a pool of webmail servers
accessing mailboxes in the cluster via IMAP (courier-imap 3.0.8). One
user may hit the mailbox a couple of times in a short period of time
when using the webmail (webmail is stateless, so it has to reread all
mailbox structure in each webmail action).
Maybe the problem is in courier-imap, so I was digging it's source code,
and found all locking stuff in liblock and maildir directories
(maildir/maildirlock.c -> maildir_lock(), liblock/mail.c ->
ll_dotlock()). I know that we are not debugging courier-imap, but it may
help.
I found a post of Lon
http://www.redhat.com/archives/linux-cluster/2004-October/msg00306.html,
that recommends using IMAP_USELOCKS and I've checked our conf and it's
enabled.
So, maybe the best way to recreate the problem is installing
courier-imap, and access a mailbox user from different clients at the
same time (in a short period of time would be best).
I hope this helps,
Thanks for your help and time,
German
So, I think it could be possible
--
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
