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

Reply via email to