On Fri, 2008-11-21 at 15:45 -0500, Rob Mangiafico wrote:
Running dovecot 1.1.6 on centOS 5 and RHEL 5.
With the settings: pop3_lock_session = yes mail_privileged_group = mail mail_location = mbox:~/:INBOX=/var/spool/mail/%u
What does ~/ expand to? What does mail_debug=yes show? The privileged locking isn't used if INBOX appears under the mail root directory. So if ~/ expands to /, /var, /var/spool or /var/spool/mail, the privileged locking isn't done.
From the log file:
Nov 21 20:29:43 ssy dovecot: auth(default): new auth connection: pid=23472 Nov 21 20:29:46 ssy dovecot: auth(default): client in: AUTH 1 PLAIN service=pop3 secured lip=127.0.0.1 rip=127.0.0.1 lport=110 rport=44480 resp=<hidden> Nov 21 20:29:46 ssy dovecot: auth(default): shadow(rlm,127.0.0.1): lookup Nov 21 20:29:46 ssy dovecot: auth(default): client out: OK 1 user=rlm Nov 21 20:29:46 ssy dovecot: auth(default): master in: REQUEST 2 23349 1 Nov 21 20:29:46 ssy dovecot: auth(default): passwd(rlm,127.0.0.1): lookup Nov 21 20:29:46 ssy dovecot: auth(default): master out: USER 2 rlm system_user=rlm uid=500 gid=500 home=/home/rlm Nov 21 20:29:46 ssy dovecot: child 23475 (pop3) killed with signal 11 Nov 21 20:29:46 ssy dovecot: POP3(rlm): Effective uid=500, gid=500 Nov 21 20:29:46 ssy dovecot: POP3(rlm): mbox: data=~/mail:INBOX=/var/spool/mail/rlm Nov 21 20:29:46 ssy dovecot: POP3(rlm): fs: root=/home/rlm/mail, index=, control=, inbox=/var/spool/mail/rlm Nov 21 20:29:46 ssy dovecot: POP3(rlm): file_lock_dotlock() failed with mbox file /var/spool/mail/rlm: Permission denied Nov 21 20:29:46 ssy dovecot: pop3-login: Login: user=<rlm>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
ls -al /var/spool/mail/ drwxrwx--x 2 root mail 4096 Nov 21 19:58 ./
dovecot -n # 1.1.6: /usr/local/etc/dovecot.conf # OS: Linux 2.6.20.1 i686 CentOS release 4.7 (Final) protocols: imap imaps pop3 pop3s ssl_cert_file: /usr/share/ssl/certs/sendmail.pem ssl_key_file: /usr/share/ssl/certs/sendmail.pem ssl_cipher_list: HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3 disable_plaintext_auth: no 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 mail_debug: yes mail_full_filesystem_access: yes mmap_disable: yes fsync_disable: yes mail_drop_priv_before_exec: yes 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 pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): %08Xv%08Xu auth default: mechanisms: plain login verbose: yes debug: yes passdb: driver: shadow userdb: driver: passwd
Could you get gdb backtrace of this crash? See http://dovecot.org/bugreport.html
I do not think it is crashing, as no matter what I do, I cannot get core dumps (in /tmp, home dir, etc...): ulimit -c unlimited
cat /proc/sys/kernel/core_pattern /tmp/%p
The reason we have dotlock as the primary format is due to procmail LDA from sendmail:
procmail -v 2>&1|grep Locking Locking strategies: dotlocking, fcntl()
I assume we have to make the "mbox_write_locks" match the procmail locking...
Actually it's not necessary. You'll need to have at least one common locking mechanism. Using only fcntl Dovecot would be enough if procmail also uses fcntl.
Ah, ok. I thought the docs implied they had to match exactly. Since we use procmail as an LDA, and occasionally pine (from uw-imap) which I believe supports fcntl, and openwebmail (not sure if fcntl is supported), I think we'll be safe with fcntl locking. Correct?
If you need me to test anything else, please let me know. Thanks!
Rob