Re: [Dovecot] Is there a straight forward way to associate login with imap process
Jack Stewart wrote: Timo Sirainen wrote: On Dec 22, 2008, at 9:01 PM, Jack Stewart wrote: Hi, What kind of a locking issue? Hangs? The clients are hanging. There are at least a couple of different types of locking issues. In both cases the dovecot.cache.index file does not update. Based on lslk, in one case the lock on the file appears persistent but not in the others. Removing the dovecot.cache.index file appears and sending a term signal to the locking process (or all processes) removes the issue for the user. As a quick follow-up to the locking issue, we found someone who has a reasonable repeatable configuration. His main client is pine and turning off IDLE in GNU biff appears to solved his locking problem. I'm not convinced this is the only (or core) issue but we've turned off IDLE (advertisement) for now. It seems to be working. This just might be a helpful stop gap for someone else, so I'm posting, although I doubt that anyone else is in a similar setup.
Re: [Dovecot] Is there a straight forward way to associate login with imap process
Timo Sirainen wrote: On Dec 22, 2008, at 9:01 PM, Jack Stewart wrote: Hi, Is there a way to associate a user's the login (imap-login) process with the user's 'imap [' process? We are trying to lock down an issue to make sure we full understand it. /proc and shared memory tools weren't particular useful. Not really with v1.1, but with v1.2 you can use %e variable in login_log_format_elements which expands to mail process PID. I guess you could also try if the change happens to apply cleanly to v1.1: http://hg.dovecot.org/dovecot-1.2/rev/29b623366e1e Just for context, we are having an intermittent locking index cache locking issue that appears to impact only a subset of our users. What kind of a locking issue? Hangs? Thank you - I'll try applying the patch to our 1.1.7 tests but it may be a few weeks before I can get back to everyone on it. The clients are hanging. There are at least a couple of different types of locking issues. In both cases the dovecot.cache.index file does not update. Based on lslk, in one case the lock on the file appears persistent but not in the others. Removing the dovecot.cache.index file appears and sending a term signal to the locking process (or all processes) removes the issue for the user. I don't yet have enough information yet to lock this down. We haven't yet reproduced it reliably but we're getting closer. ---Jack
Re: [Dovecot] Is there a straight forward way to associate login with imap process
On Dec 22, 2008, at 9:01 PM, Jack Stewart wrote: Hi, Is there a way to associate a user's the login (imap-login) process with the user's 'imap [' process? We are trying to lock down an issue to make sure we full understand it. /proc and shared memory tools weren't particular useful. Not really with v1.1, but with v1.2 you can use %e variable in login_log_format_elements which expands to mail process PID. I guess you could also try if the change happens to apply cleanly to v1.1: http://hg.dovecot.org/dovecot-1.2/rev/29b623366e1e Just for context, we are having an intermittent locking index cache locking issue that appears to impact only a subset of our users. What kind of a locking issue? Hangs?
[Dovecot] Is there a straight forward way to associate login with imap process
Hi, Is there a way to associate a user's the login (imap-login) process with the user's 'imap [' process? We are trying to lock down an issue to make sure we full understand it. /proc and shared memory tools weren't particular useful. Just for context, we are having an intermittent locking index cache locking issue that appears to impact only a subset of our users. The index files are on NFS. It may be fixed by a dovecot patch (we are at 1.1.3), adjusting our tcp_timeout on the servers, upgrading out circa 2000 load balancer, the type and configuration of the multiple simultaneous persistent clients that user is using, etc. lslk, alert logs, strace, testing the most recent 1.1.X version, and file mtime is giving us some information but we want to make everything is covered. Many thanks in advance. ---Jack -- Jack Stewart California Institute of Technology jstew...@caltech.edu / www.imss.caltech.edu
