I have just upgraded from 1.2.beta1 to 1.2.beta2. My configuration is:

[root@sbh16 ~]# dovecot -n # 1.2.beta2: /usr/local/etc/dovecot.conf # OS: Linux 2.6.18-8.1.14.el5 i686 CentOS release 5 (Final) protocols: pop3 pop3s imap imaps ssl_cert_file: /etc/postfix/sbh16-cert.pem ssl_key_file: /etc/postfix/sbh16-key.pem login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login mail_privileged_group: mail mail_location: mbox:~/Mail:INBOX=/var/spool/mail/%u mbox_write_locks: fcntl dotlock mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 pop3_lock_session(default): no pop3_lock_session(imap): no pop3_lock_session(pop3): yes auth default: mechanisms: plain apop login worker_max_count: 5 passdb: driver: passwd-file args: /usr/local/etc/dovecot.passwd passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix [root@sbh16 ~]#

This represents one change from the previous config. Previously with pop3_lock_session = yes, I needed mail_access_group = mail. With the upgrade to beta2, I changed that to mail_privileged_group = mail as shown above.

Now, during a session lasting several seconds, I see the following in maillog:

Mar 15 09:35:51 sbh16 dovecot: pop3-login: Login: user=<mark>, method=APOP, rip=68.183.193.239, lip=72.52.113.16, TLS Mar 15 09:36:01 sbh16 dovecot: POP3(mark): fstat(mark.lock) failed: Bad file descriptor Mar 15 09:36:04 sbh16 dovecot: POP3(mark): Disconnected: Logged out top=0/0, retr=1/1919972, del=0/328, size=5381253 Mar 15 09:36:04 sbh16 dovecot: child 9023 (pop3) killed with signal 11 (core dumps disabled)

This does not occur with shorter sessions lasting only a few seconds or less. The only symptom is the log messages. The client sees nothing unusual, at least in this case where the session is a retrieval of one large message. I haven't tried long sessions retrieving multiple messages.

If I remove pop3_lock_session = yes, the issue does not occur. I don't think I need it. I put it in a long time ago to attempt to solve a problem that was actually caused by something else. Since removing it does seem to avoid this issue, I will leave it out, but I'm reporting this anyway as it seems there may be some underlying problem.

-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan