Peer Heinlein
2010-Jan-18 23:21 UTC
[Dovecot] No filelocking at "shared-mailboxes" dictionary?
Using imapsync I changed many ACLs on many accounts simultaneously in four concurrent IMAP-sessions. I started with an empty file "shared-mailboxes". But after the sync the file "shared-mailboxes" has been crashed. I found broken lines and I'm missing some entrys. Is it possible that there's no filelocking on that file? I used the ext3 filesystem. That's what shred-mailboxes looks like at the moment: shared/shared-box 1 shared/shared-boxes/user/user1.example.com/user2.example.com 1 .example.com/user5.example.com 1 hared/shared-boxes/user/user6.example.com/user4.example.c2442203233424^? 1 ser/user7.example.com/user2.example.com Peer dovecot -n: # 1.2.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.27.39-0.2-default x86_64 openSUSE 11.1 (x86_64) protocols: imap imaps managesieve ssl_cert_file: /etc/ssl/old.pem ssl_key_file: /etc/ssl/old.pem shutdown_clients: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(managesieve): /usr/lib/dovecot/managesieve-login login_process_per_connection: no login_max_processes_count: 512 max_mail_processes: 1024 mail_max_userip_connections(default): 40 mail_max_userip_connections(imap): 40 mail_max_userip_connections(managesieve): 10 verbose_proctitle: yes mail_uid: vmail mail_gid: vmail mail_location: maildir:~/Maildir mail_executable(default): /usr/lib/dovecot/imap-usernamenmigration mail_executable(imap): /usr/lib/dovecot/imap-usernamenmigration mail_executable(managesieve): /usr/lib/dovecot/managesieve mail_plugins(default): quota imap_quota acl imap_acl mail_plugins(imap): quota imap_quota acl imap_acl mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib64/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib64/dovecot/modules/imap mail_plugin_dir(managesieve): /usr/lib64/dovecot/modules/managesieve namespace: type: private separator: / inbox: yes list: yes subscriptions: yes namespace: type: shared separator: / prefix: zz_SHARED_ACCOUNTS/%%u/ location: maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u list: yes lda: postmaster_address: postmaster at iea-dpc.org mail_plugins: quota acl sieve mail_plugin_dir: /usr/lib64/dovecot/modules/lda quota_full_tempfail: yes auth default: mechanisms: plain login digest-md5 cram-md5 verbose: yes debug: yes debug_passwords: yes passdb: driver: passwd-file args: /etc/dovecot/userdb userdb: driver: passwd-file args: /etc/dovecot/userdb userdb: driver: static args: uid=5001 gid=5001 socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 432 user: vmail group: vmail plugin: quota: maildir quota_rule: *:storage=102400 acl: vfile acl_shared_dict: file:/var/lib/dovecot/shared-mailboxes sieve: ~/.dovecot.sieve sieve_dir: ~/sieve -- Heinlein Professional Linux Support GmbH Linux: Akademie - Support - Hosting http://www.heinlein-support.de Tel: 030 / 40 50 51 - 0 Fax: 030 / 40 50 51 - 19 Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin
Timo Sirainen
2010-Jan-18 23:31 UTC
[Dovecot] No filelocking at "shared-mailboxes" dictionary?
On 19.1.2010, at 1.21, Peer Heinlein wrote:> I started with an empty file "shared-mailboxes". But after the sync the > file "shared-mailboxes" has been crashed. I found broken lines and I'm > missing some entrys. > > Is it possible that there's no filelocking on that file?The file is always created by creating a temporary file, locking the file by link()ing it to a dotlock file, reading existing data, applying changes, and writing the data to it and then rename()ing it over the original file. There isn't really any way to corrupt data inside the file, because the whole file is always recreated.> hared/shared-boxes/user/user6.example.com/user4.example.c2442203233424^? > 1 > ser/user7.example.com/user2.example.comIf it's a Dovecot bug, it's more likely a memory corruption problem. I don't see any obvious reasons though. Can you easily reproduce this? Running via valgrind could be interesting then.