- dovecot - dovecot.org

Inconsistent mdbox index while running doveadm altmove
by Ricardo Machini Barbosa 01 Mar '16

01 Mar '16

Hello, I was performing doveadm altmove for one account while this mailbox was being accessed. Dovecot version: 2.2.21 Mailbox format: mdbox Command: doveadm altmove -u user1(a)domain.com.br before 360d This command took about 5 minutes to finish and during the execution I found some log messages: Feb 25 19:57:51 dovecot: imap(user1(a)domain.com.br): Error: mdbox map /var/mail/user1/mdbox/storage/dovecot.map.index corrupted: Unexpectedly lost INBOX uid=77 map_uid=76 Feb 25 19:57:51 dovecot: imap(user1(a)domain.com.br): Internal error occurred. Refer to server log for more information. [2016-02-25 19:57:51] in=4798 out=1361819 deleted=0 expunged=0 trashed=0 Feb 25 19:57:51 dovecot: imap(user1(a)domain.com.br): Warning: fscking index file /var/mail/user1/mdbox/storage/dovecot.map.index Feb 25 19:58:15 dovecot: imap(user1(a)domain.com.br): Error: /var/mail/user1/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index reset, view is now inconsistent Feb 25 19:58:20 dovecot: imap(user1(a)domain.com.br): Error: /var/mail/user1/mdbox/mailboxes/Rascunhos/dbox-Mails/dovecot.index reset, view is now inconsistent After that these messages moved to alternate storage disappeared from the mailbox/IMAP but these files were all on alternative storage. I had to execute doveadm force-resync -u user1(a)domain.com.br INBOX to recovery this mailbox, but losing all e-mail's flags. I should do some kind of lock before running the command altmove ? Regards, Ricardo

2 1

Re: severe fork() problems with new dovecot server
by J. Niklas 01 Mar '16

01 Mar '16

On 01.03.2016 18:21, Dolf Schimmel wrote: > Recently I played around a little with cgroups where you can limit the max number of processes per cgroup. > Could it be that, perhaps, you've stumbled upon such a limit? > Systemd does contain all services by default in their own cgroup afaik, > so it could be that you're using it unknowingly. Yes, yes, \o/ ;-) #> systemctl status dovecot.service * dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/dovecot.service.d `-ulimits.conf Active: active (running) since Tue 2016-03-01 15:28:29; 4h 24min ago Main PID: 10098 (dovecot) Tasks: 204 (limit: 512) CGroup: /system.slice/dovecot.service There ist my "512". The way of systemd, ignoring all the config stuff that has been there for decades while inposing its own, complex and very sparsely documented ruleset on top is beginning to seriously annoy me. At least I would have expected some sort of syslog message. Just for the records, this can be changed by adding e.g. TasksMax=4096 to the /etc/systemd/system/dovecot.service.d/ulimits.conf I cited in my OP. Now I'll have to wait and see how things will evolve tomorrow. Thank you so much for the great hint! -- kind regards, Jon

2 1

severe fork() problems with new dovecot server
by J. Niklas 01 Mar '16

01 Mar '16

Hi all, I am getting to you because I am pretty desperate by now. Please read this and share your ideas. I set up a new Mail server with roughly 750 active accounts on it, based on the usual dovecot+postfix+amavis+sql based vmail setup. This is not the first time I did something like this, but admittedly my largest setup so far. I took my time to setup everything pretty straight and stable and migrated all accounts in time with almost no glitches using imapc and pop3c. Things started out smoothly - until the first business morning when the log suddenly began to pop messages like these: dovecot: master: Error: service(imap): fork() failed: Resource temporarily unavailable dovecot: master: Error: service(pop3): fork() failed: Resource temporarily unavailable The error is not confined to a certain service. There are no other messages in dmesg or syslog which could help in closing in on the root cause. The server always runs at load around 0.4 to 0.5 and has plenty of RAM and Disk, too. Of course I checked resource limits and cranked up everything I could possibly think of to numbers that should easily suffice: /etc/security/limits.conf: daemon soft nproc 2048 daemon hard nproc 3128 dovecot soft nproc 2048 dovecot hard nproc 3128 vmail soft nproc 2048 vmail hard nproc 3128 vmail soft nofile 32768 vmail hard nofile 49152 /etc/systemd/system/dovecot.service.d/ulimits.conf: [Service] LimitNOFILE=65534 However, all my attempts on resolving the problem were futile so far. To work around the problem I implemented a log watcher which constantly looks for the fork failure and dumps some debug info before restarting dovecot to make the problem "go away" - until dovecot hits whatever barrier there is again. Here are today's numbers I gathered from this: > forkdump_03-01_09-42: pop=3, imap=446, all=503, postfix:22, sys: 716 > forkdump_03-01_10-09: pop=9, imap=444, all=510, postfix:28, sys: 741 > forkdump_03-01_10-42: pop=5, imap=450, all=507, postfix:25, sys: 748 > forkdump_03-01_11-18: pop=5, imap=451, all=512, postfix:29, sys: 757 > forkdump_03-01_11-48: pop=3, imap=474, all=511, postfix:37, sys: 765 > forkdump_03-01_12-23: pop=7, imap=444, all=511, postfix:22, sys: 752 > forkdump_03-01_12-53: pop=3, imap=444, all=503, postfix:24, sys: 747 > forkdump_03-01_13-21: pop=3, imap=458, all=504, postfix:31, sys: 766 > forkdump_03-01_13-41: pop=4, imap=451, all=505, postfix:23, sys: 755 > forkdump_03-01_14-35: pop=5, imap=436, all=502, postfix:31, sys: 768 > forkdump_03-01_14-59: pop=3, imap=445, all=501, postfix:27, sys: 764 > forkdump_03-01_15-28: pop=6, imap=452, all=507, postfix:25, sys: 769 There you see the number of pop3 and imap childs in the process list as well as the total number of all dovecot processes and all postfix processes, summarized directly after the fork problem appears in the log. The last column is the sum of all processes in the system. Here is a run where the numbers are measured as the server approaches the last entry in the list above. > 15:26:15: pop=3, imap=432, all=485, VSZ: 14353k, postfix:30, sys: 749 > 15:26:30: pop=4, imap=435, all=490, VSZ: 14497k, postfix:30, sys: 754 > 15:26:45: pop=3, imap=439, all=492, VSZ: 14560k, postfix:28, sys: 754 > 15:27:00: pop=3, imap=444, all=497, VSZ: 14711k, postfix:28, sys: 760 > 15:27:15: pop=4, imap=442, all=496, VSZ: 14673k, postfix:25, sys: 756 > 15:27:30: pop=4, imap=444, all=497, VSZ: 14721k, postfix:25, sys: 757 > 15:27:46: pop=3, imap=446, all=498, VSZ: 14756k, postfix:25, sys: 758 > 15:28:01: pop=3, imap=446, all=497, VSZ: 14718k, postfix:24, sys: 756 > 15:28:16: pop=3, imap=455, all=507, VSZ: 15018k, postfix:25, sys: 767 > 15:28:18: pop=3, imap=455, all=507, VSZ: 15018k, postfix:25, sys: 767 > 15:28:20: pop=3, imap=452, all=504, VSZ: 14931k, postfix:25, sys: 764 ---- service(pop3): fork() failed: Resource temporarily unavailable ---- > 15:28:22: pop=4, imap=452, all=505, VSZ: 14954k, postfix:25, sys: 770 > 15:28:24: pop=4, imap=452, all=505, VSZ: 14954k, postfix:25, sys: 770 > 15:28:26: pop=4, imap=451, all=504, VSZ: 14925k, postfix:25, sys: 769 > 15:28:28: pop=5, imap=451, all=506, VSZ: 14980k, postfix:25, sys: 771 ---- dovecot restart complete ---- > 15:28:30: pop=3, imap=11, all=22, VSZ: 485k, postfix:25, sys: 282 > 15:29:00: pop=4, imap=65, all=83, VSZ: 2293k, postfix:26, sys: 344 > 15:29:31: pop=3, imap=91, all=111, VSZ: 3129k, postfix:27, sys: 373 It always seems to happen shortly after the number of dovecot processes goes beyond 500. The VSZ column is the VSZ sum of all dovecot procs. The number of files opened by vmail (lsof -u <vmailuid> | wc -l) at that moment usually is between 13k and 15k. sysctl fs.file-nr mostly is around 16k total but the system limit is set way higher (at 1532853) However, as you can see in the following dump, there is no process_limit or whatever being set to 500 or 512 or similar. # --------- su vmail -c "ulimit -Ha:" --------------- core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 60026 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 49152 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 3128 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited # ---------------- dovecot -n (mildly anonymized) --------------- # 2.2.18: /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.8 (0c4ae064f307+) # OS: Linux 4.4.0-8-generic x86_64 Ubuntu Xenial Xerus (development branch) xfs auth_cache_negative_ttl = 0 auth_cache_size = 50 M auth_mechanisms = plain login default_client_limit = 10000 dict { quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext } hostname = my.mail.host imap_client_workarounds = delay-newmail lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes lda_original_recipient_header = X-Original-To listen = * mail_location = sdbox:/mailsrv/users/%d/%u mail_plugins = quota notify mail_log fts managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate namespace inbox { inbox = yes location = mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Junk { auto = subscribe special_use = \Junk } mailbox Sent { auto = subscribe special_use = \Sent } mailbox Trash { auto = subscribe special_use = \Trash } prefix = } passdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } plugin { fts_autoindex = yes quota = dict:User quota::proxy::quota sieve = file:~/sieve;active=~/.dovecot.sieve sieve_dir = ~/sieve stats_refresh = 30s stats_track_cmds = yes } postmaster_address = postmaster(a)my.mail.host protocols = " imap lmtp sieve pop3" service anvil { client_limit = 11227 } service auth { client_limit = 11324 unix_listener /mailsrv/spool/private/auth { group = postfix mode = 0666 user = postfix } } service dict { unix_listener dict { mode = 0600 user = vmail } } service imap-login { process_limit = 10000 process_min_avail = 5 service_count = 0 vsz_limit = 2 G } service imap { process_limit = 2048 vsz_limit = 2 G } service lmtp { inet_listener lmtp { address = 127.0.0.1 port = 24 } } service managesieve-login { inet_listener sieve { port = 4190 } } service pop3-login { process_limit = 1024 process_min_avail = 3 service_count = 0 vsz_limit = 2 G } service pop3 { process_limit = 1024 } service stats { fifo_listener stats-mail { mode = 0600 user = vmail } } ssl_cert = </etc/ssl/local/my.mail.host.crt.pem ssl_key = </etc/ssl/local/my.mail.host.key.pem userdb { args = /etc/dovecot/dovecot-sql.conf.ext driver = sql } verbose_proctitle = yes protocol lmtp { mail_plugins = quota notify mail_log fts quota sieve } protocol lda { mail_plugins = quota notify mail_log fts sieve } protocol imap { mail_max_userip_connections = 15 mail_plugins = quota notify mail_log fts imap_quota stats imap_stats } protocol pop3 { mail_max_userip_connections = 15 } # ------------ end dovecot -n ------------- So, here I am, out of ideas for the moment. Do you have any? -- kind regards, Jonathan

1 0

What happened to dovecot.fi?
by Pieter Koorts 01 Mar '16

01 Mar '16

Hi All, Any news about what happened to dovecot.fi ? Is enterprise or the S3 backend plugin still available? Reason for asking is every attempt to access the dovecot.fi website shows it as down and has done for a while. Pieter

2 1

Returning custom autoexpunge for user's INBOX
by Tom Johnson 01 Mar '16

01 Mar '16

I want to be able to have custom autoexpunge settings for different users. I have it working for various folders (draft, junk, trash), but I can't seem to get it working for the user's primary inbox. In my user_query (I'm using mysql), I'm returning entries like this in the userdb_import field: namespace/inbox/mailbox/autoexpunge=5d namespace/inbox/mailbox/Drafts/autoexpunge=5d namespace/inbox/mailbox/Junk/autoexpunge=5d namespace/inbox/mailbox/Trash/autoexpunge=5d And everything works fine for Drafts, Junk, and Trash, but not for the main inbox. The logs show: Debug: Unknown userdb setting: plugin/namespace/inbox/mailbox/autoexpunge=5d I've also tried variations, trying to get the namespace correct for the main inbox, but they all get the same "Unknown userdb setting" error: namespace/inbox/mailbox/autoexpunge=5d namespace/inbox/mailbox/inbox/autoexpunge=5d namespace/inbox/mailbox/Inbox/autoexpunge=5d namespace/inbox/mailbox/INBOX/autoexpunge=5d I suspect I'm just giving the wrong namespace for the primary inbox. What's the right way to do this? Tom

2 2

UnicodeData
by Vincent Dahmen 29 Feb '16

29 Feb '16

Hey guys, there seem to be a problem with wget and/or the unicode webserver. During the make process there are several files wich are download from the unicode server. I can access them manually but both curl and wget failing to get it. Are they any other mirrors or anyone else expiring this bug? Greetings

2 3

Re: sieve_extprograms - double linebreaks at filtering
by Hajo Locke 29 Feb '16

29 Feb '16

Hello, Am 09.09.2015 um 13:30 schrieb Stephan Bosch: > > > Op 9-9-2015 om 12:37 schreef Hajo Locke: >> Hello, >> >> >> Am 09.09.2015 um 11:26 schrieb Stephan Bosch: >>> >>> >>> Op 8-9-2015 om 13:10 schreef Hajo Locke: >>>> Hello List, >>>> >>>> i have a problem when using sieve-plugin sieve_extprograms. I use >>>> dovecot 2.2.18 and bundled pigeonhole 0.4.6 (Ubuntu 14.04.3 LTS) >>>> >>>> i have enabled sieve_extprograms and vnd.dovecot.filter to send >>>> mail to user-defined script and get changed content back. >>>> My script previously was used with procmail and is working fine. >>>> Using same script with vnd.dovecot.filter leads to odd behavior. >>>> I already found out the problem itself: >>>> By sending Mailcontent to filter-programm it seems that >>>> sieve/sieve_extprograms is adding additional linebreaks to every >>>> line of complete mail. >>>> Please see this image to clarify: >>>> http://r31i.imgup.net/header8d56.jpg?l=de >>>> Every lineending got additional windows-lineendings, which leads to >>>> problems with processing scripts. >>>> Piping mails by procmail to same script is working without >>>> problems, because this mails are recieved "clean" without the "^M". >>> >>> Well, the specified format for an internet message like e-mail has >>> CRLF line endings everywhere. That's why this happens now: >>> >>> http://hg.rename-it.nl/dovecot-2.2-pigeonhole/file/5df1b6d72ec2/src/plugins… >>> >>> >>> But maybe that is not such a good idea in a UNIX environment. I >>> think I can just make it configurable. >> >> ahh, there it is. i think just commenting out this line in my sources >> will result in some errors. Is there a possibility for me to make a >> quickfix in my sources? (use other function or something like that) > > You can replace it with the i_stream_create_lf() function, which > enforces LF rather than CR+LF, which would be what you need. Unfortunately i have to continue this issue. During my last updates this problem is occured again. This are my versions: # 2.2.21 (): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.11 (6ddf62b87f60+) # OS: Linux 3.13.0-77-generic x86_64 Ubuntu 14.04.4 LTS I tried to configure the linebreaks in my plugin section of /etc/dovecot/dovecot.conf by: sieve_extprograms_input_eol = lf But it seems to have no effect. Is this configured the right way or i have to use 0.4.12? Currently it looks like this: plugin { sieve = ~/sieve/.dovecot.sieve sieve_before = ~/sieve_before/.dovecot_before.sieve sieve_after = ~/sieve_after/.dovecot_after.sieve sieve_plugins = sieve_extprograms sieve_extensions = +vnd.dovecot.pipe +vnd.dovecot.filter +vnd.dovecot.execute +editheader sieve_pipe_bin_dir = /usr/local/bin/ sieve_filter_bin_dir = /usr/local/bin/ sieve_dir = ~/sieve sieve_global_dir = /etc/dovecot/sieve/ sieve_extprograms_input_eol = lf } > > Regards, > > Stephan. > > Thanks, Hajo

2 2

Queries are not being sent to solr when search on server issued via imap client.
by ralph.jones＠modolingo.de 29 Feb '16

29 Feb '16

I traced the network communication with the solr server with tcpdump: sudo tcpdump -i any -A -vvv port 8080 I logged into the imap server via telnet (actually openssl) and issued the command ". search body <string>". About 20 results were returned within about half a second. Nothing was seen in tcpdump. When I issue "doveadm search box <string>", I can see the search string in the output of tcpdump and also in the solr logs. Solr seems to have been initialized correctly, in that when I issue a query via curl, I receive the correct results. I am using: dovecot 2.2.13 (debian jessie) libsolr-java 3.6.2+dfsg-5 relevant config: mail_plugins = fts fts_solr acl virtual plugin { fts = solr fts_solr = url=http://localhost:8080/solr/ debug ... }

2 1

Dovecot sieve - How to check which username a mail is being delivered to?
by Yannik Sembritzki 27 Feb '16

27 Feb '16

Hi everyone, I am looking for a way to check which mailbox an email is being delivered to in a global sieve filter. After not being able to find some kind of variable that is populated by dovecot automatically, I tried to use the `Delivered-To` header. I tried a check like this: header :is "delivered-to" "<user(a)domain.org>" Unfortunately, this does not only match the first occurence of the header (which can be assumed is added by dovecot), but any occurence of this header in the email, which could be added due to previous deliveries and forwards, or just cause of malice. Is there any way to achieve this? Best regards, Yannik

2 3

Assertion crash: (idx * array->element_size < array->buffer->used)
by Joseph Tam 26 Feb '16

26 Feb '16

Log message: Traceback is hex gibberish: if symbolic traceback is needed, I'll recompile with "cc -g" and retest. Panic: file ../../../src/lib/array.h: line 219 (array_idx_i): assertion failed : (idx * array->element_size < array->buffer->used) (Similar to http://dovecot.org/pipermail/dovecot/2015-February/099771.html) IMAP command that provoked the crash: x1 FETCH 3 (BODY) Dovecot version: 2.2.19, Solaris10 (I don't think doveconf -n is relevant, but willing to provide if needed). It seems like a mailbox index issue. Removing, then recreating the indices gets rid of the crash. I saved these indices if it will help. Joseph Tam <jtam.home(a)gmail.com>

1 0