Hello Timo,
I'm running
dovecot-1.0.rc15 (imap and pop) postfix-2.3.5,1 procmail-3.22_6 (which is my LDA)
on FreeBSD 6.1-STABLE
I'm still using the mbox format (I'm planning to migrate to Maildir soon), mailboxes are on an NFS filesystem.
I regulary see stale dotlocks files (either from dovecot (29 bytes, hold the pid of the process) or procmail (1 byte) and processes stucked in Disk Wait state.
The only way I can get ridd of them is to
restart nfslocking
remove the .lock file
change the inode of the mailbox filelocking strategies are
fcntl for mbox_read in dovecot
dotlock fcntl for mbox_write in dovecot
dotlock fcntl for procmailso I can't figure out why I see such stale locks and processes.
Note : I disabled nfs attribute caching so I avoid cache related issues (such as a dotlock showing up late, etc...)
Besides, I often see several imap-login processes for the same remote IP address. Does it means the user has several instances of his UA running or is it the behavior of some UA (Eudora ? Thunderbird ?) even if only one instance is run by the user. In any case, wouldn't that be dead-lock/stale lock prone ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, 2007-01-19 at 21:08 +0100, Thomas Hummel wrote:
I regulary see stale dotlocks files (either from dovecot (29 bytes, hold the pid of the process) or procmail (1 byte) and processes stucked in Disk Wait state.
What exactly does "processes stuck in disk wait" state mean? "D" in ps output? If you ktrace the process, does it show you what syscall it's waiting on?
I'm thinking maybe your problem is that your nfs.lockd breaks itself, or something else in the NFS setup breaks itself..
The only way I can get ridd of them is to
restart nfslocking remove the .lock file change the inode of the mailbox file
By this you mean get rid of the processes? Dovecot itself gives up trying to lock files after 5 minutes. If it doesn't, then the problem is in the kernel.
On Fri, Jan 19, 2007 at 10:36:28PM +0200, Timo Sirainen wrote:
On Fri, 2007-01-19 at 21:08 +0100, Thomas Hummel wrote:
What exactly does "processes stuck in disk wait" state mean? "D" in ps output?
yes. A process in disk (or other short term, uninterruptible) wait.
If you ktrace the process, does it show you what syscall it's waiting on?
I planned to try that. Still didn't do it.
I'm thinking maybe your problem is that your nfs.lockd breaks itself, or something else in the NFS setup breaks itself..
May be the case indeed. How about some issue with large mailboxes ? Would you recommend tweaking some options in dovecot.conf (such as lock timeouts...etc..) ?
The only way I can get ridd of them is to
restart nfslocking remove the .lock file change the inode of the mailbox file
By this you mean get rid of the processes?
Yes. I get rid of the Disk Wait process and everything restart fine (I forgot to mention I stop postfix and dovecot before that sequence).
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, Jan 19, 2007 at 10:36:28PM +0200, Timo Sirainen wrote:
What exactly does "processes stuck in disk wait" state mean? "D" in ps
[...]
What about the multiple imap-logins for the same IP remote address : is that normal ?? is that a bad client implementation effect ? Would that be dead-lock prone ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, Jan 19, 2007 at 09:08:02PM +0100, Thomas Hummel wrote:
Besides, I often see several imap-login processes for the same remote IP address. Does it means the user has several instances of his UA running or is it the behavior of some UA (Eudora ? Thunderbird ?) even if only one instance is run by the user. In any case, wouldn't that be dead-lock/stale lock prone ?
Some IMAP clients do open multiple connections in parallell. For example, the default for Thunderbird is up to a maximum of five connections. You can set this inside Account Settings -> Server Settings -> Advanced and looking for "Maximum number of server connections to cache."
-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia
participants (3)
-
Glenn Leavell
-
Thomas Hummel
-
Timo Sirainen