> Hi Ellie
>
> Thanks a lot, I will try to build and test 2.4.20
Maybe try this:
http://www.invoca.ch/pub/packages/cyrus-imapd/RPMS/ils-7/SRPMS/cyrus-imapd-2.4.20-2.el7.src.rpm
Regards,
Simon
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/piperma
Hi Ellie
Thanks a lot, I will try to build and test 2.4.20
22.02.2019 04:20, ellie timoney пишет:
Hi Ivan,
#7 0x56193ed6382e in idle_update ()
with cyrus-imapd 2.4.17 (cyrus-imapd-2.4.17-13.el7.x86_64 rpm)
It looks like this version is old enough to still be using signal handlers in
Hi Ivan,
> #7 0x56193ed6382e in idle_update ()
> with cyrus-imapd 2.4.17 (cyrus-imapd-2.4.17-13.el7.x86_64 rpm)
It looks like this version is old enough to still be using signal handlers in
its IMAP IDLE implementation. This is known to be a problem, and IDLE was
rewritten to not use sig
Hello
I have gdb'ed the locked process, backtrace is below. It seems that
problem occurs when imapd process catch a signal when is inside malloc()
call. The signal handler has a malloc() call too, so finally there is
interlock between two mallocs
I have only a few time to investigate because
Jonk, thank you for the idea. Somewhat looks strange as old mail server
worked w/o this problem 5+ years. But the system environment changed
dramatically, may be some filesystem quircks are significant for this
locks...
I will try gdb'ing the process when problem occurs once more
13.12.2018 1
Without running gdb on the process, I have no idea, but your problem
sounds similar to something we hit a very long time ago:
See https://www.oakton.edu/user/3/jwade/cyrus/Readme.html
In our cases, the problem was the imapd process that was holding the
lock was trying to obtain a second lock o
Hello
We had a company mail server under Oracle Linux 6 (a clone of RHEL6)
with cyrus-imapd 2.3.16 working for years w/o problems. There are >9M
messages in ~9500 mailboxes in two partitions. Daily mail traffic is
20-50K messages.
Some weeks ago we migrated the server to a new one under Orac
