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=pop3secured 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: USER2
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 21|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
