Jason Tucker writes:
On Mon, 2 Apr 2001, Sam Varshavchik wrote:
Jason Tucker writes:
(gdb) bt
#0 0xdfbb1523 in _libc_sigpause ()
#1 0xdfbea6c1 in sigpause ()
#2 0x804a60e in loop (fd=6) at ldapaliasd.c:699
#3 0x804a815 in start () at ldapaliasd.c:756
#4 0x804a9ed in main (argc=2, argv=0x8047b78) at ldapaliasd.c:832
That's the whole thing.
You did not indicate if courierldapaliasd is actually working. If LDAP
alias resolving is actually working, this indicates that your platform's
sigpause() implementation sucks eggs, that's all...
No... it doesn't seem to be working. However, I don't know if it's because
of a software problem, or a configuration problem. It does seem to be
querying the LDAP server, however, every time I send a message to the
test alias, slapd reports a "badfilter", and courier reports "450 Service
temporarily unavailable".
So it's a configuration issue.
It appears that slapd reports a "badfilter" whenever you search for an
attribute that isn't in any of you're loaded schemas. Based on the courier
docs, it looks like courierldapaliasd simply requires the "mail" and
"maildrop" attributes (and optionally, the "source", "vdomain", and
"vuser" attributes).
It looks like I've got my directory set up OK, but something's not
working.
Make sure that your bind is set up correctly.
I don't think there's a problem here. You are getting back a prompt 451
service unavailable, which is the expected response in this situation --
LDAP configuration failure. The high CPU utilization is probably due to a
broken implementation of sigpause().
19 messages in net.sourceforge.lists.courier-usersRe: Infinite loop (WAS: Re: [courier-...
