I sent this update to the list on March 28th, but it (along with others?)
didn't seem to make it. So, here it is...
I've done quite a lot more looking into this problem of mine. Things are
*not* as catastrophic as I initially thought.
The crashing of the IMSP daemon is dependent on what's in the global
options file. I first looked at upgrading to Cyrus imsp a while back.
Initially, I was having real troubles getting authentication to work
(before I discovered the magic /usr/local/lib/sasl/imspd.conf requirement).
While I was investigating, I at some point added the lines...
imsp.sasl.plain.PAM
imsp.sasl.login.PAM
to my global options file. These are the entries which cause imspd to die
when given a "get imsp.*" or "get *". When I remove them, all is well.
Thanks to all who responded to my initial message.
Cheers...
On Tue, 27 Mar 2001 08:24:30 -0800 Rob Tanner <[EMAIL PROTECTED]> wrote:
> Me too! MessagingDirect's contract support sucks, and getting the next
> release out the door always seems to be more important than supporting
> the current version (and we should pay good money for the privilege of
> their ignoring problems) Besides, their stuff is proprietary and not
> near as flexible.
>
> Getting off my soap-box, cyrus-imsp v1.6a3 seems to have problems (at
> least on Solaris), although I've never had a problem with segfaults.
> You might look for inconsistent libraries. Typically, the segfaults
> are caused by more than one version of BerkeleyDB libs on the system.
> But as your not doing authentication at the point of the segfault, I
> can't see how your immediate problem could be related to Berkeley in
> particular.
>
> If all else fails, my other suggestion is to use imspd v1.6a2. Most of
> the intentional changes between v1.6a2 and v1.6a3 are related to LDAP
> support (which is now broken, but works fine in v1.6a2). As far as the
> unintentional changes... well, maybe you just found one. For myself,
> especially since the LDAP support is critical for me, v1.6a2 was the
> solution.
>
> Now, if someone could only tell me how to get imspd to run out of inetd
> so I can run it as user "cyrus" instead of "root", I'd be tickled pink.
>
> -- Rob
>
>
> --On Tuesday, March 27, 2001 10:37:02 AM +0100 Richard Hopkins
> <[EMAIL PROTECTED]> wrote:
>
> >
> > Along with quite a number of others, I guess, I'm now actively
> > looking at upgrading from ESYS/Execmail/MessagingDirect (whatever
> > the heck they are called now) IMSP and IMAP to Cyrus.
> >
> > I have a problem with Simeon and Execmail interworking with the Cyrus
> > IMSP server which seems pretty much identical to what was described
> > back in April 1996 - see below - in a nutshell, no address book
> > problems, no option saving problems, but unable to load options.
> >
> > I've done some tracing, and what I see is that when Execmail issues a
> > "<tag> get imsp.*" command, Cyrus imspd dies. Using telnet as my
> > client, I see...
> >
> > * OK Cyrus IMSP version 1.6a3 ready
> > . get common.*
> > * OPTION common.date "Tue, 27 Mar 2001 10:10:38 +0100" [READ-ONLY]
> > * OPTION common.delivery.hosts "(stingray.cse.bris.ac.uk)" [READ-ONLY]
> > * OPTION common.domain bris.ac.uk [READ-ONLY]
> > * OPTION common.from "" [READ-ONLY]
> > * OPTION common.sent.mailbox sentmail [READ-ONLY]
> > . OK get completed
> > . get imsp.*
> > Connection closed by foreign host.
> >
> >
> > At the server end (running imspd under "truss"), I see...
> >
> > read(5, " . g e t c o m m o n".., 4096) = 16
> > time() = 985684238
> > poll(0xFFBE8920, 1, 30000) = 1
> > write(5, " * O P T I O N c o m".., 295) = 295
> > poll(0xFFBE9920, 1, 1800000) (sleeping...)
> > poll(0xFFBE9920, 1, 1800000) = 1
> > read(5, " . g e t i m s p . *".., 4096) = 14
> > Incurred fault #6, FLTBOUNDS %pc = 0xFF136DCC
> > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
> > Received signal #11, SIGSEGV [caught]
> > siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
> > sigaction(SIGSEGV, 0xFFBE9518, 0xFFBE9598) = 0
> > getpid() = 7202 [7201]
> > kill(7202, SIGSEGV) = 0
> > Received signal #11, SIGSEGV [default]
> > siginfo: SIGSEGV pid=7202 uid=0
> > *** process killed ***
> >
> >
> > This does appear to be a bug in the cyrus server and is obviously
> > catastophic to my plans to upgrade. Is there any possibility of a fix?
> >
> > Cheers...
> >
> >
> _ _ _ _ _ _ _ _ _ _
> /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
>
> Rob Tanner
> UNIX and Networks Manager
> Linfield College, McMinnville OR
> (503) 434-2558 <[EMAIL PROTECTED]>
>
Richard Hopkins,
Information Services,
Computer Centre,
University of Bristol,
Bristol, BS8 1UD, UK
Tel +44 117 928 7859
Fax +44 117 929 1576
RFC-822: [EMAIL PROTECTED]
