service imap pid nnnn in BUSY state: terminated abnormally

   I sent this last Friday but it never appeared (and I did not get any
non-delivery report), so I'm trying again.

   I am attempting to upgrade a Cyrus Murder from 2.3.12p2 to 2.3.14.  The
mupdate and backend servers are happy at 2.3.14, but on the frontends while
I can login successfully, attempting to select a folder fails with messages
like

May 29 12:13:59 kil-imap-13 master[15558]: process 15584 exited, signaled to 
death by 11
May 29 12:13:59 kil-imap-13 master[15558]: service imap pid 15584 in BUSY 
state: terminated abnormally

This is on Red Hat Linux 5 (2.6.18-128.1.6.el5PAE kernel).

I have not found anything in the Cyrus mailing list archive that looks like 
this.  A Google search did find a similar problem from just a couple of weeks 
ago with a Debian installation which was attributed to "packages sasl2-bin, 
libsasl2-2 and libsasl2-modules".

I am using the Red Hat SASL RPMs, version 2.1.22-4 which appears to be the
latest.  This has worked so far, so I have not installed SASL from Cyrus
itself.  The Cyrus SASL 2.1.23 announcement only talks about a "potential"
buffer overflow which suggests to me that the change there is not relevant

Should I switch to Cyrus SASL?

The mailbox database is skiplist, seen and subscription are flat, and quota
is legacy; others are Berkeley.

Re: service imap pid nnnn in BUSY state: terminated abnormally

>    I sent this last Friday but it never appeared (and I did not get any
> non-delivery report), so I'm trying again.
>
>    I am attempting to upgrade a Cyrus Murder from 2.3.12p2 to 2.3.14.  The
> mupdate and backend servers are happy at 2.3.14, but on the frontends
> while
> I can login successfully, attempting to select a folder fails with
> messages
> like
>
> May 29 12:13:59 kil-imap-13 master[15558]: process 15584 exited, signaled
> to
> death by 11
> May 29 12:13:59 kil-imap-13 master[15558]: service imap pid 15584 in BUSY
> state: terminated abnormally

I'm not sure that could be related but there is a bug in 2.3.14 which can
result in unexpected behaviour. It may be unrelated but you better check
it out:
http://www.mail-archive.com/info-cyrus <at> lists.andrew.cmu.edu/msg37575.html

>
> This is on Red Hat Linux 5 (2.6.18-128.1.6.el5PAE kernel).
>
> I have not found anything in the Cyrus mailing list archive that looks
> like
> this.  A Google search did find a similar problem from just a couple of
> weeks
> ago with a Debian installation which was attributed to "packages
> sasl2-bin,

Re: service imap pid nnnn in BUSY state: terminated abnormally

On Mon, 1 Jun 2009 at 16:33 Simon Matter wrote to Aidan Evans and...

> I'm not sure that could be related but there is a bug in 2.3.14 which can
> result in unexpected behaviour. It may be unrelated but you better check
> it out:
> http://www.mail-archive.com/info-cyrus <at> lists.andrew.cmu.edu/msg37575.html

   Thank you, I had noticed that and thought it was a bit outside what I was
experiencing, but I'm going to have another look.

P.S.  Both my posts, this morning's and Friday's, are in the list archive,
but I did not receive a copy, nor did the list copy of your email come
appear.  I checked my list settings and I am supposed to get a list copy.

Aidan Evans   | Networks & Systems
(902)494-3332 | Dalhousie University, Halifax, N.S., Canada
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Self-healing mailbox?

--On 31. Mai 2009 22:41:52 +1000 Bron Gondwana <brong <at> fastmail.fm> wrote:

>> I interpret the "System I/O error" to be the IOERROR from the line
>> before, i.e. not actually an I/O error but rather a corrupt file. The
>> error does not show on any of the previous days, nor does it show today.
>
> Sounds to me like it was copying the record to the cyrus.expunge.NEW
> file each time for the earlier days (and failing, so skipping the
> entire mailbox), but now the record has actually expired, so it
> doesn't need to copy the cache record to the cyrus.cache.NEW file,
> and hence never looks at it.
>
> Meaning: yes, it did heal itself!

Thanks for the explanation!
--

-- 
     .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
.:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:.

----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Load testing Cyrus IMAP

Were currently running Cyrus on a single RHEL 4 (64 bit) and are 
planning on a migrating to 3 HP DL380 G5's running RHEL 5 (64 bit) with 
a fiber channel backend.  I want to test the performance but not sure 
what to use.  Does anybody have any recommendations on how to test the 
load via a script with variable users?

Thanks!

-Bhavesh
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Load testing Cyrus IMAP

mstone is worth checking out.

Cheers,
Ken

On Tue, Jun 02, 2009 at 03:28:35PM -0700, Bhavesh Lad wrote:
> Were currently running Cyrus on a single RHEL 4 (64 bit) and are 
> planning on a migrating to 3 HP DL380 G5's running RHEL 5 (64 bit) with 
> a fiber channel backend.  I want to test the performance but not sure 
> what to use.  Does anybody have any recommendations on how to test the 
> load via a script with variable users?
> 
> Thanks!
> 
> -Bhavesh
> ----
> Cyrus Home Page: http://cyrusimap.web.cmu.edu/
> Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
> 
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

Re: Cyrus APIs ?

2009/5/29 Bron Gondwana <brong <at> fastmail.fm>:
>>   - custom authentification mechanism (for single sign-on purpose,
>> because kerberos doesn't fit everywhere)
>
> BYO saslauthd protocol daemon.  We have one written in Perl that does
> all sorts of clever.  Just put this in your imapd.conf
>
> sasl_pwcheck_method: saslauthd
>
> And have your daemon listen on a unix socket at:
>
> /var/state/saslauthd/mux
>
> You need to speak the saslauthd protocol, which is a packed string
> format.  We parse it in Perl like this:
>
>  my $LoginName = get_counted_string($Self->{server}{client});
>  my $Password = get_counted_string($Self->{server}{client});
>  my $Service = lc get_counted_string($Self->{server}{client});
>  my $Realm = get_counted_string($Self->{server}{client});
>
> And return one of:
>
>  use constant SASL_SUCC_RESP  => pack("nA3", 2, "OK\000");
>  use constant SASL_FAIL_RESP  => pack("nA3", 2, "NO\000");
>
> (with this function - slightly ugly code, but it works)
>
> sub get_counted_string {
>  my $fh = shift;

Migrate from 2.2. to 2.3 with ldap

Hi,

I'm a bit stuck. I want to migrate from 2.2.12 to a recent 2.3.x server.

cyrus.conf includes
  ptloader      cmd="ptloader" listen="/mail/imap/ptclient/ptsock"
     prefork=1

imapd.conf includes
  ldap_* parameters
  sasl_ldap* parameters (with auxprop ldapdb)

Current install is with ldap enabled, build with
  --with-ldap=/opt/freeware
  --with-pts=ldap \
  --with-auth=pts

In 2.3. there is only "with-ldap" left.
Is this enough to build with the intended ldap support?

The available rpms from openSuSE Build Service (openSuSE 11.1 or SLES 
11) form SLES 11 all do not have the with-ldap option set.
I cannot find any ptloader binary after install.
Do I not need any ptloader for ldap anymore?

Marc
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

murder and autocreate (I know it is not supported)

Hi.
I'm setting up a test environment with frontend, backend, murder (currently 1, 
1, 1 respectively). All using RPMs on recent RedHat systems.

I have read in the docs that the autocreate patch does not work with murder, 
and I have experienced it too. But...

... if I leave the autocreate ON on backends only, and then simulate an IMAP 
access or mail delivery right at the backend level, I should not get into 
troubles, right?

Just to ease the creation of mailboxes, especially during this deployment 
test. Or perhaps even after if our complex tools won't like the cyradm Perl 
interface. (yes, we will have a look at gosa and korreio)

TIA,
Paolo

----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

sasl_pwcheck_method

----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html