December 2009 - dovecot

[Dovecot] pop3+leave messages on server
by Papp Tamas 24 Jan '10

24 Jan '10

hi All, I have a srange problem. Before dovecot there was a courier imap and it worked just fine. The client(s) are the same then before, so I think, this is an server side problem. I have a user with Outlook and he uses pop3 and leaves messages on server. Sometimes the messages get downloaded again, when he starts the outlook. Not all, but 7-9 hours back. uidl format is like it's suggested: pop3_uidl_format = %08Xu%08Xv Any idea, what's wrong and what I can do? Thank you very much, tamas

6 16

[Dovecot] Thinderbird+delete+move to Trash folder
by Papp Tamás 22 Jan '10

22 Jan '10

hi All, I have a problem, which makes me headache. I can't find out, what is the problem. I have a mail szerver, which works just fine as expected, TB move messages to trash folder after I delete it, and they are moved. I have an other server. If I delete a message, it doesn't move to the Trash folder. As deleted_to_trash plugin is installed, if I only mark messages as deleted, they are moved to thee Trash folder and also with Outlook works well. It's like when a messages is deleted from TB, the message get moved to the Trash folder, and it's expunged(?) at the same time. Is it possible? Could you help me? The system is Ubuntu 9.04 with docecot 1.2.5-0~auto+0 from http://xi.rename-it.nl/debian/, but builded by myself for x86_64. Thank you, tamas

6 15

[Dovecot] Two different issues with dovecot 1.1.13
by Stuart Rowan 20 Jan '10

20 Jan '10

Hi Timo, I'm using Debian backports.org dovecot-imapd, 1:1.1.13-2~bpo50+1. I've got two different issues, a reoccurring, seemingly harmless one about "Corrupted index cache file" (boring.txt) and one that went bonkers over the least few days (bt.txt) causing much spamming of the logs. I've made bt.txt stop happening by just rm'ing dovecot.index* : find Maildir/ -type f -name 'dovecot.index*' -print0 | xargs -0r rm ... which I realise may not be the most helpful thing to have done from your point of view. Anyway I just wanted to let you know about both of these. If one or both are already known about or already fixed by a later version of Dovecot, great and sorry for the noise! If not, and you want any more information etc., let me know. Many thanks, Stu. dovecot: 2009-07-28 10:23:16 Error: IMAP(strr): Corrupted index cache file /home/local/strr/Maildir/dovecot.index.cache: record continues outside its allocated size dovecot: 2009-07-28 10:23:56 Error: IMAP(strr): Corrupted index cache file /home/local/strr/Maildir/dovecot.index.cache: record continues outside its allocated size dovecot: 2009-07-28 08:05:54 Panic: IMAP(strr): file index-mail-headers.c: line 77 (index_mail_parse_header_finish): assertion failed: ((match[match_idx] & HEADER_MAT CH_FLAG_FOUND) == 0) dovecot: 2009-07-28 08:05:54 Error: IMAP(strr): Raw backtrace: imap [0x48dbf2] -> imap [0x48dc73] -> imap [0x48d346] -> imap(index_mail_parse_header+0x617) [0x4545f7] -> imap [0x483284] -> imap [0x483478] -> imap(i_stream_read+0x2c) [0x491d7c] -> imap(i_stream_read_data+0x46) [0x491f16] -> imap(message_get_body_size+0x108) [0x4885 a8] -> imap [0x4226c3] -> imap(imap_fetch+0x162) [0x420852] -> imap(cmd_fetch+0x23c) [0x41a27c] -> imap [0x41e46c] -> imap [0x41e51d] -> imap [0x41eb25] -> imap(clien t_input+0x63) [0x41efd3] -> imap(io_loop_handler_run+0xcb) [0x49515b] -> imap(io_loop_run+0x18) [0x4945c8] -> imap(main+0x3da) [0x426bea] -> /lib/libc.so.6(__libc_sta rt_main+0xe6) [0x7f0e851941a6] -> imap [0x418859] dovecot: 2009-07-28 08:05:54 Error: child 20007 (imap) killed with signal 6 (core dumps disabled) dovecot: 2009-07-28 08:05:56 Panic: IMAP(strr): file index-mail-headers.c: line 77 (index_mail_parse_header_finish): assertion failed: ((match[match_idx] & HEADER_MAT CH_FLAG_FOUND) == 0) dovecot: 2009-07-28 08:05:56 Error: IMAP(strr): Raw backtrace: imap [0x48dbf2] -> imap [0x48dc73] -> imap [0x48d346] -> imap(index_mail_parse_header+0x617) [0x4545f7] -> imap [0x483284] -> imap [0x483478] -> imap(i_stream_read+0x2c) [0x491d7c] -> imap(i_stream_read_data+0x46) [0x491f16] -> imap(message_get_body_size+0x108) [0x4885 a8] -> imap [0x4226c3] -> imap(imap_fetch+0x162) [0x420852] -> imap(cmd_fetch+0x23c) [0x41a27c] -> imap [0x41e46c] -> imap [0x41e51d] -> imap [0x41eb25] -> imap(clien t_input+0x63) [0x41efd3] -> imap(io_loop_handler_run+0xcb) [0x49515b] -> imap(io_loop_run+0x18) [0x4945c8] -> imap(main+0x3da) [0x426bea] -> /lib/libc.so.6(__libc_sta rt_main+0xe6) [0x7f2edf08b1a6] -> imap [0x418859] dovecot: 2009-07-28 08:05:56 Error: child 20984 (imap) killed with signal 6 (core dumps disabled)

2 5

[Dovecot] Virtual folder, Program terminated with signal 6
by Matthias Rieber 19 Jan '10

19 Jan '10

Hi, I've regularly crashes with a certain virtual folder. Erasing the dovecot-index.* files help just for few hours/days. Here are to backtraces: Core was generated by `imap'. Program terminated with signal 6, Aborted. [New process 25893] #0 0xf7df8556 in raise () from /lib/libc.so.6 #0 0xf7df8556 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xf7df9d78 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x080f2d25 in default_fatal_finish (type=<value optimized out>, status=0) at failures.c:160 backtrace = 0x88ee860 "imap [0x80f2d11] -> imap [0x80f2d92] -> imap [0x80f26e9] -> imap(index_search_result_update_flags+0x295) [0x80b2305] -> /usr/local/lib/dovecot/imap/lib20_virtual_plugin.so [0xf7da937d] -> /usr/local/l"... #3 0x080f2d92 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=0x810b88c "file %s: line %d (%s): assertion failed: (%s)", args=0xff8b2ea4 "\\S\021\bW") at failures.c:443 No locals. #4 0x080f26e9 in i_panic (format=0x810b88c "file %s: line %d (%s): assertion failed: (%s)") at failures.c:207 No locals. #5 0x080b2305 in index_search_result_update_flags (result=0x9400cb0, uids=0xff8b3150) at index-search-result.c:87 search_arg = {next = 0x89024c0, type = SEARCH_UIDSET, value = {subargs = 0x0, seqset = {arr = {buffer = 0x88ee4a8, element_size = 8}, v = 0x88ee4a8, v_modifiable = 0x88ee4a8}, str = 0x0, time = 0, size = 0, flags = 0, search_flags = 0, thread_type = MAIL_THREAD_NONE, keywords = 0x0, modseq = 0x0, search_args = 0x0, search_result = 0x0}, context = 0x0, hdr_field_name = 0x0, not = 0, match_always = 0, result = -1} ret = <value optimized out> __PRETTY_FUNCTION__ = "index_search_result_update_flags" #6 0xf7da937d in virtual_sync_backend_boxes (ctx=0x93f6660) at virtual-sync.c:733 _data_stack_cur_id = 4 i = 0 ret = 155151376 #7 0xf7daa25b in virtual_storage_sync_init (box=0xb20e070, flags=65) at virtual-sync.c:1486 sync_ctx = <value optimized out> ret = <value optimized out> #8 0x080b6ab2 in mailbox_sync (box=0x6525, flags=65, status_items=239, status_r=0xff8b3338) at mail-storage.c:593 ctx = <value optimized out> #9 0x080651b8 in cmd_select_full (cmd=0x88fbc88, readonly=false) at cmd-select.c:273 client = (struct client *) 0x88fb9f8 box = (struct mailbox *) 0x0 ctx = (struct imap_select_context *) 0x88fbd28 args = (const struct imap_arg *) 0x88fe508 mailbox = 0x88ee2b8 "obfuscated" ret = <value optimized out> __PRETTY_FUNCTION__ = "cmd_select_full" #10 0x08065919 in cmd_select (cmd=0x88fbc88) at cmd-select.c:389 No locals. #11 0x08067bfc in client_command_input (cmd=0x88fbc88) at client.c:612 client = (struct client *) 0x88fb9f8 command = <value optimized out> __PRETTY_FUNCTION__ = "client_command_input" #12 0x08067c99 in client_command_input (cmd=0x88fbc88) at client.c:661 client = (struct client *) 0x88fb9f8 command = <value optimized out> __PRETTY_FUNCTION__ = "client_command_input" #13 0x08067e0d in client_handle_input (client=0x88fb9f8) at client.c:702 _data_stack_cur_id = 3 ret = false remove_io = <value optimized out> handled_commands = false __PRETTY_FUNCTION__ = "client_handle_input" #14 0x0806876f in client_input (client=0x88fb9f8) at client.c:753 cmd = <value optimized out> output = (struct ostream *) 0x88fbbac bytes = <value optimized out> __PRETTY_FUNCTION__ = "client_input" #15 0x080fbac0 in io_loop_handler_run (ioloop=0x88f61a8) at ioloop-epoll.c:208 ctx = (struct ioloop_handler_context *) 0x88f6c18 event = (const struct epoll_event *) 0x88f6c58 list = (struct io_list *) 0x88fbc30 io = (struct io_file *) 0x88fbc08 tv = {tv_sec = 1, tv_usec = 707102} t_id = 2 msecs = <value optimized out> ret = 1 i = 0 j = 0 call = <value optimized out> #16 0x080faf30 in io_loop_run (ioloop=0x88f61a8) at ioloop.c:335 No locals. #17 0x0807127a in main (argc=) at main.c:327 No locals. Core was generated by `imap'. Program terminated with signal 6, Aborted. [New process 26275] #0 0xf7ea4556 in raise () from /lib/libc.so.6 #0 0xf7ea4556 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xf7ea5d78 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x080f2d25 in default_fatal_finish (type=<value optimized out>, status=0) at failures.c:160 backtrace = 0x88d9860 "imap [0x80f2d11] -> imap [0x80f2d92] -> imap [0x80f26e9] -> imap(index_search_result_update_flags+0x295) [0x80b2305] -> /usr/local/lib/dovecot/imap/lib20_virtual_plugin.so [0xf7e5537d] -> /usr/local/l"... #3 0x080f2d92 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=0x810b88c "file %s: line %d (%s): assertion failed: (%s)", args=0xffe03774 "\\S\021\bW") at failures.c:443 No locals. #4 0x080f26e9 in i_panic (format=0x810b88c "file %s: line %d (%s): assertion failed: (%s)") at failures.c:207 No locals. #5 0x080b2305 in index_search_result_update_flags (result=0x9318e10, uids=0xffe03a20) at index-search-result.c:87 search_arg = {next = 0x893dfe8, type = SEARCH_UIDSET, value = {subargs = 0x0, seqset = {arr = {buffer = 0x88d94a8, element_size = 8}, v = 0x88d94a8, v_modifiable = 0x88d94a8}, str = 0x0, time = 0, size = 0, flags = 0, search_flags = 0, thread_type = MAIL_THREAD_NONE, keywords = 0x0, modseq = 0x0, search_args = 0x0, search_result = 0x0}, context = 0x0, hdr_field_name = 0x0, not = 0, match_always = 0, result = -1} ret = <value optimized out> __PRETTY_FUNCTION__ = "index_search_result_update_flags" #6 0xf7e5537d in virtual_sync_backend_boxes (ctx=0x930e9e8) at virtual-sync.c:733 _data_stack_cur_id = 4 i = 0 ret = 154202008 #7 0xf7e5625b in virtual_storage_sync_init (box=0x88ebcf0, flags=65) at virtual-sync.c:1486 sync_ctx = <value optimized out> ret = <value optimized out> #8 0x080b6ab2 in mailbox_sync (box=0x66a3, flags=65, status_items=239, status_r=0xffe03c08) at mail-storage.c:593 ctx = <value optimized out> #9 0x080651b8 in cmd_select_full (cmd=0x88e6c88, readonly=false) at cmd-select.c:273 client = (struct client *) 0x88e69f8 box = (struct mailbox *) 0x0 ctx = (struct imap_select_context *) 0x88e6d28 args = (const struct imap_arg *) 0x88e9508 mailbox = 0x88d92b8 "obfuscated" ret = <value optimized out> __PRETTY_FUNCTION__ = "cmd_select_full" #10 0x08065919 in cmd_select (cmd=0x88e6c88) at cmd-select.c:389 No locals. #11 0x08067bfc in client_command_input (cmd=0x88e6c88) at client.c:612 client = (struct client *) 0x88e69f8 command = <value optimized out> __PRETTY_FUNCTION__ = "client_command_input" #12 0x08067c99 in client_command_input (cmd=0x88e6c88) at client.c:661 client = (struct client *) 0x88e69f8 command = <value optimized out> __PRETTY_FUNCTION__ = "client_command_input" #13 0x08067e0d in client_handle_input (client=0x88e69f8) at client.c:702 _data_stack_cur_id = 3 ret = false remove_io = <value optimized out> handled_commands = false __PRETTY_FUNCTION__ = "client_handle_input" #14 0x0806876f in client_input (client=0x88e69f8) at client.c:753 cmd = <value optimized out> output = (struct ostream *) 0x88e6bac bytes = <value optimized out> __PRETTY_FUNCTION__ = "client_input" #15 0x080fbac0 in io_loop_handler_run (ioloop=0x88e11a8) at ioloop-epoll.c:208 ctx = (struct ioloop_handler_context *) 0x88e1c18 event = (const struct epoll_event *) 0x88e1c58 list = (struct io_list *) 0x88e6c30 io = (struct io_file *) 0x88e6c08 tv = {tv_sec = 1, tv_usec = 627183} t_id = 2 msecs = <value optimized out> ret = 1 i = 0 j = 0 call = <value optimized out> #16 0x080faf30 in io_loop_run (ioloop=0x88e11a8) at ioloop.c:335 No locals. #17 0x0807127a in main (argc=) at main.c:327 No locals. kind regards, Matthias

2 4

[Dovecot] fts squat non-english search for 2 words
by vuser1＠test123.ru 19 Jan '10

19 Jan '10

Hello, It looks I encoutered a bug or misconfiguration. fts_squat search for subject and body works excellent for English mails. For non-English (in particular, Russian) it works only when query consists of 1 word. Phrases - 2 and more words - always returns nothing. Example: search for "planet" ("планета") returns results, search for "Earth" ("Земля") also returns results, but "planet Earth" ("планета Земля") returns nothing. But there are emails having exact phrase "planet Earth". This problem occurs only for non-English queries, both for search in subject and in email body. I tried web-mail Horde 3.2 and Thunderbird. I turned fts plugin off and it correctly finds phrases with 2 and more russian words! So problem is squat. Is it a bug or known config issue? OS: Debian 5.0, installed as openVZ container inside Ubuntu 8.04. Dovecot: 1.2.4, from backports.org Ext3 filesys dovecot -n -------------- # 1.2.4: /etc/dovecot/dovecot.conf # OS: Linux 2.6.24-24-openvz i686 Debian 5.0.3 simfs log_timestamp: %Y-%m-%d %H:%M:%S protocols: imap imaps pop3 pop3s ssl_cert_file: /etc/ssl/test123/test123.full.crt ssl_key_file: /etc/ssl/test123/priv/test123.key disable_plaintext_auth: 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(pop3): /usr/lib/dovecot/pop3-login last_valid_uid: 500 mail_privileged_group: mail mail_location: maildir:/var/mail/%u mbox_write_locks: fcntl dotlock mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): quota imap_quota fts fts_squat mail_plugins(imap): quota imap_quota fts fts_squat mail_plugins(pop3): mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(pop3): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh lda: postmaster_address: postmaster(a)test123.ru hostname: test123.ru sendmail_path: /usr/sbin/sendmail auth_socket_path: /var/run/dovecot/auth-master mail_plugins: quota sieve log_path: info_log_path: auth default: mechanisms: plain login user: nobody passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: passwd userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: prefetch socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: mail master: path: /var/run/dovecot/auth-master mode: 432 user: vmail group: mail plugin: acl: vfile:/etc/dovecot/acls trash: /etc/dovecot/trash.conf fts: squat fts_squat: partial=4 full=20 --------------- (with full=10 problem persists)

2 7

[Dovecot] Dovecot-deliver sometimes fails when message set to discard via sieve
by Steve Wagner 19 Jan '10

19 Jan '10

Hi, sometimes mails that i discard via sieve gets delivered to my inbox and i can not figure out why. So i hope you can give me a hint. My setup is: I use a self compiled dovecot 1.2.4 with installed sieve and managesieve plugin. Incoming mails a processed by Postfix and the delivered to Procmail. Procmail invokes Spamassassin and discard all mails marked as spam. The other mails are passed to Dovecot deliver this way: :0 w | /opt/dovecot/libexec/dovecot/deliver For moving mails to subdirectorys this works always, but not for mails that are discard via Sieve. Examples are: if header :contains "List-Id" "git.vger.kernel.org" { if header :contains "Subject" "[ANNOUNCE]" { fileinto "Announce"; stop; } if header :contains "Subject" "[ANN]" { fileinto "Announce"; stop; } if header :contains "Subject" "[PATCH" { discard; stop; } fileinto "Lists.Git"; stop; } or if header :contains "Organization" "web.de" { discard; stop; } This often works, but sometimes it fails. Procmail reports then that deliver reported an error (but not which) and delivers them to my inbox. There are also no message in dovecots or dovecot delivers log file. Dose anybody have an idea? Steve

3 12

[Dovecot] Dovecot Proxy and environment variables
by BaQs 19 Jan '10

19 Jan '10

Dear list, First of all, I am French so excuse my bad english. I am currently using dovecot proxy feature, using sql backend. I "proxy" the imap/pop requests to another server, let's say server2. On server2, I use a script to keep up to date a "pop before smtp auth" database. I used mail_executable = /path/to/this/script.sh ... My problem is: the $IP environment variable on server2 is the proxy's IP. How could I give a variable from proxy to server2, or simply get the real client public IP ? Thanks a lot in advance for your answers Pierre. PS: let me also thank very much dovecot developers and community !

3 7

[Dovecot] sieve 0.1.14: vacation encodes Subject twice
by Roland Rosenfeld 11 Jan '10

11 Jan '10

Hi! I noticed the following problem in dovecot-1.2-sieve-0.1.14: The following vacation causes trouble with the Subject line: if not exists ["List-Id", "List-Post"] { vacation :days 7 :addresses ["test(a)netcologne.de"] :subject "=?utf-8?b?w4TDlsOc?= sadasd" "Bin gerade nicht hier."; } As you can see, the Subject is already MIME encoded according to RFC2047. Starting with sieve 0.1.14 the subject is now encoded by sieve again, so I get the following in my vacation mail: Subject: =?utf-8?q?=3D=3Futf-8=3Fb=3Fw4TDlsOc=3F=3D?= sadasd As you can see, the RFC2047 encoding is RFC2047 encoded, which results in an unreadable subject. According to RFC5230 section 4.3 this shouldn't happen: The ":subject" parameter specifies a subject line to attach to any vacation response that is generated. UTF-8 characters can be used in the string argument; implementations MUST convert the string to [RFC2047] encoded words if and only if non-ASCII characters are present. Implementations MUST generate an appropriate default subject line as specified below if no :subject parameter is specified. If I understand this right, sieve should do the RFC2047 encoding only if the string is non-ASCII. But the RFC2047 encoded string is already ASCII, so it should not be encoded a second time. I just compared this with sieve 0.1.13, which behaves different: It does not encode the Subject header at all. As long as the managesieve client (in our situation Horde/IMP) encodes the subject, everything works correct, while we run into trouble with 0.1.14. I think that there needs to some mechanism in sieve that checks whether the subject contains non-ASCII and does the encoding only in this case. I just checked out, that 0.1.14 does not encode a non RFC2047 encoded 7bit subject, while a 7bit subject starting with =?utf-8?... is encoded twice. Tschoeeee Roland -- Roland Rosenfeld - Content Delivery - NED - Technik NetCologne Gesellschaft für Telekommunikation mbH - HRB 25580, AG Köln Am Coloneum 9 50829 Köln Tel.: +49-221-2222-373 Fax: +49-221-2222-7373 Geschäftsführer: Werner Hanf, Karl-Heinz Zankel

4 6

[Dovecot] problem with uidlist
by Cor Bosman 06 Jan '10

06 Jan '10

In both 1.2.6 and 1.2.7 (probably also before that, but dont have logs) im seeing quite a few of these: Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2650: 1257768394._smtp.mxdrop238.41874,S=17304:2,Sad (uid 34270 -> 37166) I never really looked at it because it doesnt seem to be causing many problems, but i just noticed something that probably hints at the cause.. Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2650: 1257768394._smtp.mxdrop238.41874,S=17304:2,Sad (uid 34270 -> 37166) Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2651: 1257769385._smtp.mxdrop155.53889,S=305996:2,Sad (uid 34271 -> 37167) Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2652: 1257769984._smtp.mxdrop107.23815,S=320781:2,Sabd (uid 34272 -> 37168) Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2670: 1257858287._smtp.mxdrop131.43563,S=26827:2,Sad (uid 34311 -> 37186) Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2671: 1257858303._smtp.mxdrop238.88513,S=2143:2,Sad (uid 34312 -> 37187) Nov 17 12:45:12 userimap10.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 2672: 1257858868._smtp.mxdrop217.21298,S=8548:2,Sad (uid 34314 -> 37188) Nov 17 12:45:12 userimap7.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 994: 1244800736._smtp.mxdrop237.59318,S=4573:2,Sad (uid 32467 -> 35510) Nov 17 12:45:12 userimap7.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 995: 1244807927._smtp.mxdrop215.53275,S=439887:2,Sad (uid 32468 -> 35511) Nov 17 12:45:12 userimap7.xs4all.nl dovecot: IMAP(xxxxxxx): /var/spool/mail/dovecot-control/c/c0/xxxxxxx/INBOX/.INBOX/dovecot-uidlist: Duplicate file entry at line 996: 1244828590._smtp.mxdrop111.81795,S=3606:2,RSabd (uid 32469 -> 35512) This customer seems to be using our IMAP service from 2 machines at the same time. Possibly a webmail service and a desktop imap client. It may be that both machines are trying to manipulate the uidlist at the same time, causing who knows that kind of corruption. This could maybe explain some of the coredumps im seeing in 1.2.7? This is on Debian/Lenny, using NFS spool and NFS control/indexes. Timo, you asked in private mail a few days ago if we're sure the filenames are forever unique. Im sure. I double checked it in the source code. The above filenames are timestamp_hostname.pid, and that seems pretty unique right? Regards, Cor

3 2

Re: [Dovecot] dovecot-1.2.8 imap crash (with backtrace)
by David Halik 06 Jan '10

06 Jan '10

I found this post from a couple of weeks ago: http://www.mail-archive.com/dovecot@dovecot.org/msg24127.html Any update on this? I'm experiencing the same issue. Out of a user population of 4000, I get about 20 of these dumps a day, so it's not major issue, but I thought I'd follow up. Here is an example: http://pastebin.com/f29c55de5 I can provide a more detailed debug log from teh core dump if necessary, but since the above email already had it I figured I'd wait. Note this is *not* the same issue as: - maildir: v1.2.7 and v1.2.8 caused assert-crashes in maildir_uidlist_records_drop_expunges() I applied those patches to my 1.2.8 installation before 1.2.9 was released and that immediately fixed the expunge crash, but the array_delete bug is still there. dovecot -n --------------- bash-3.2# /usr/sbin/dovecot -n # 1.2.8: /etc/dovecot.conf # OS: Linux 2.6.18-164.6.1.el5 x86_64 CentOS release 5.4 (Final) listen: * ssl_cert_file: /rci/local/certs/imapd-pop3d.pem ssl_key_file: /rci/local/certs/imapd-pop3d.pem disable_plaintext_auth: yes login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login login_max_processes_count: 2048 max_mail_processes: 2048 first_valid_uid: 100 mail_location: maildir:~/Maildir:INDEX=/rci/nqu%h/dovecot:CONTROL=/rci/nqu%h/dovecot mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mail_drop_priv_before_exec: yes mail_executable(default): /rci/local/etc/convert-courier-imap.sh mail_executable(imap): /rci/local/etc/convert-courier-imap.sh mail_executable(pop3): /rci/local/etc/convert-courier-pop.sh mail_plugin_dir(default): /usr/lib64/dovecot/imap mail_plugin_dir(imap): /usr/lib64/dovecot/imap mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3 pop3_uidl_format(default): %08Xu%08Xv pop3_uidl_format(imap): %08Xu%08Xv pop3_uidl_format(pop3): UID%u-%v namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes auth default: passdb: driver: pam args: dovecot userdb: driver: passwd -- ================================ David Halik System Administrator OIT-CSS Rutgers University dhalik(a)jla.rutgers.edu ================================

3 22