similar to: 2.3.7 slower than 2.3.6?

On 15 Jul 2019, at 23.17, Ralf Hildebrandt via dovecot <dovecot at dovecot.org> wrote: > > * Ralf Hildebrandt via dovecot <dovecot at dovecot.org>: >> We're using dovecot (via LMTP) as a backup for all incoming mail. >> >> I upgraded from 2.3.6 to 2.3.7 on the 12th: >> 2019-07-12 14:35:44 upgrade dovecot-imapd:amd64 2:2.3.6-2~bionic 2:2.3.7-8~bionic

* Ralf Hildebrandt via dovecot <dovecot at dovecot.org>: > We're using dovecot (via LMTP) as a backup for all incoming mail. > > I upgraded from 2.3.6 to 2.3.7 on the 12th: > 2019-07-12 14:35:44 upgrade dovecot-imapd:amd64 2:2.3.6-2~bionic 2:2.3.7-8~bionic > > and it seems that 2.3.7 is slower than 2.3.6 -- mail to the backup > IMAP box is suddenly taking quite

On 16 Jul 2019, at 11.15, Ralf Hildebrandt via dovecot <dovecot at dovecot.org> wrote: > > * Timo Sirainen via dovecot <dovecot at dovecot.org>: > >>> And alas, I had a look at the monitoring and found that disk IO has >>> increase A LOT after the update: https://www.arschkrebs.de/images/dovecot-disk-io-increase.png >>> >>> I zoomed in

* Timo Sirainen via dovecot <dovecot at dovecot.org>: > > And alas, I had a look at the monitoring and found that disk IO has > > increase A LOT after the update: https://www.arschkrebs.de/images/dovecot-disk-io-increase.png > > > > I zoomed in and found that the sudden increace in IO coincides with > > the update to 2.3.7 (14:35):

On 1 Oct 2019, at 16.45, Ralf Hildebrandt via dovecot <dovecot at dovecot.org> wrote: > > * Ralf Hildebrandt via dovecot <dovecot at dovecot.org>: > >> But why is that? Why would the index file be updated so often? > > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from back in July. Fixed by

* Ralf Hildebrandt via dovecot <dovecot at dovecot.org>: > * Timo Sirainen <timo at sirainen.com>: > > > > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from back in July. > > > > Fixed by https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98 and will be in the soon-to-be-released v2.3.8. > > I

I set up system copying all mails to a backup system. This used to work without a hitch - now in the last few days mails would pile up in the Postfix Queue, waiting to be delivered using the lmtp transport into dovecot. So dovecot was being slow, but why? After all, nothing changed. After reading some articles on stackoverflow I found a way of finding out which file gets the most IO: % sysdig

I'm encountering a crash which this command: % doveadm import -u restore at backup.invalid mdbox:/home/copymail2/mdbox '' mailbox INBOX header X-Spam Yes SAVEDBEFORE 2019-05-23 doveadm(restore at backup.invalid): Panic: file mail-index-util.c: line 10 (mail_index_uint32_to_offset): assertion failed: (offset < 0x40000000) doveadm(restore at backup.invalid): Error: Raw backtrace:

Due to the ongoing performance issues with 2.0.x I switched back to 1.2.15 yesterday evening, with no changes to the machine or my users. (I migrated from 1.2.15 to 2.0.x by converting the existing config) Today, we have MUCH LESS load, with the same number of logins/min. I cannot say what exactly causes this immense increase in load, but one observation is that the time spent in system() has

One of our squid proxies crashed today. I was able to make a screenshot of it's last utterings - and since ext3 is being mentioned there, I thought I'd mention it here: http://www.arschkrebs.de/images/proxy-cbf-2-crash.png # uname -a Linux proxy-cbf-2 2.6.21 #1 SMP Thu Apr 26 11:17:54 CEST 2007 i686 GNU/Linux # mount /dev/cciss/c0d0p5 on / type auto (rw,errors=remount-ro) tmpfs on

All over a sudden the getquota plugin in SquirrelMail doesn't work anymore. I activated debugging an got: IMAP command sent: a001 GETQUOTAROOT "INBOX" IMAP response received: Array ( [0] => * QUOTAROOT "INBOX" "" [1] => * QUOTA "" () ) A manual test results in: . GETQUOTAROOT "INBOX" * QUOTAROOT "INBOX"

Core was generated by /usr/local/libexec/dovecot/imap'. Program terminated with signal 6, Aborted. #0 0xb7fb6410 in __kernel_vsyscall () (gdb) bt #0 0xb7fb6410 in __kernel_vsyscall () #1 0xb7e85f15 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7e87891 in abort () from /lib/i686/cmov/libc.so.6 #3 0x080ce499 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=0x80e8f54

from dovecot -n: plugin: fts: squat quota: maildir quota_rule: Trash:storage=100M quota_warning: storage=10%% /usr/local/scripts/quota-warning 90 quota_warning2: storage=5%% /usr/local/scripts/quota-warning 95 quota_warning3: storage=1%% /usr/local/scripts/quota-warning 99 trash: /usr/local/etc/dovecot-trash.conf The quota warning that used to work in 1.0.10 (with the

I'm getting "Maximum number of mail processes exceeded" messages when 512 imap Processes are active. Dovecot reports: Warning: fd limit 1024 is lower than what Dovecot can use under full load (more than 1712). Either grow the limit or change login_max_processes_count and max_mail_processes settings But in my /var/service/dovecot/run script I use: #!/bin/sh mkdir /var/core chmod

I'm encountering lots of Oct 31 11:14:25 postamt dovecot: pipe() failed: Too many open files errors around midday ever since the latest upgrade to 1.0.7. The errors appear in pairs like this one: Oct 31 11:20:01 postamt dovecot: pipe() failed: Too many open files Oct 31 11:20:01 postamt dovecot: imap-login: Internal login failure: user=<username>, method=PLAIN, rip=193.175.174.239,

http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz.sig * IDLE: Interval between mailbox change notifies is now 1 second, because some clients keep a long-running IDLE connection and use other connections to actually read the mails. * SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft

http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz.sig * IDLE: Interval between mailbox change notifies is now 1 second, because some clients keep a long-running IDLE connection and use other connections to actually read the mails. * SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft

Found this today multiple times for the same user: Aug 16 16:59:38 postamt dovecot: IMAP(username): file strfuncs.c: line 165 (p_strndup): assertion failed: (max_chars != (size_t)-1) Aug 16 16:59:38 postamt dovecot: IMAP(username): Raw backtrace: imap [0x80c6d53] -> imap(i_fatal+0) [0x80c6795] -> imap(p_strndup+0x38) [0x80d8316] -> imap(t_strndup+0x22) [0x80d86d7] ->

I get: Making all in auth make[3]: Entering directory /usr/src/dovecot/src/auth' rm -f libpassword.a ar cru libpassword.a mycrypt.o password-scheme.o password-scheme-md5crypt.o password-scheme-otp.o password-scheme-rpa.o ranlib libpassword.a gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-sql -I../../src/lib-settings -I../../src/lib-ntlm -I../../src/lib-otp

I'm getting these in my log: Jul 17 11:40:42 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:40:42 postamt dovecot: child 26581 (login) killed with signal 6 Jul 17 11:51:12 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:51:12 postamt dovecot: child