> Hi!
>
> Le ven 23/04/2004 à 12:32, Craig Ringer a écrit :
>> >
>> > Apr 21 11:07:19 lmtpunix[16815]: DBERROR db4: Logging region out of
>> > memory; you may need to increase its size
>> > --
>>
>> If you can, I'd stop the master and then run db_verify on deliver.db. I
>> woul
Chris Harms wrote:
After some tinkering, removing the IP address from /etc/hosts was the
magic bullet. However, this raises a larger question:
If S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP tells sendmail not to rewrite
the address (allegedly), why was it still doing it?
Probably a better question f
Rob,
I've included just the tail end of the strace confirming the segmentaion
fault, but there was no corresponding core dump. Do I have to do something
special to cause it to dump core?
recvfrom(6, "\221,\205\200\0\1\0\1\0\2\0\2\0011\003255\003171\00210"...,
1024, 0, {sa_family=AF_INET, sin_
On Wed, 21 Apr 2004, Rob Tanner wrote:
> I installed Cyrus IMSP server version 1.7b on a RH AS3 server and configured
> it with LDAP to use our LDAP server as the backend for the global
> addressbook. I am using the dfault distro libs for LDAP, and imsp builds
> okay except I get a bunch of "war
On Wed, 2004-04-21 at 19:38, Noll Janos wrote:
>
> Apr 21 11:07:19 lmtpunix[16815]: DBERROR db4: Logging region out of
> memory; you may need to increase its size
> Apr 21 11:07:19 lmtpunix[16815]: DBERROR: opening /var/imap/deliver.db:
> Cannot allocate memory
> Apr 21 11:07:19 lmtp
On Thu, 22 Apr 2004, Moritz Both wrote:
> It looks llike it may be related to re-entrace in the sasl libraries.
> See this:
[snip]
> The problem was that pam_ldap was compiled with sasl, and the sasl
> libraries are not reentrant. Thus a double free bug was triggered.
Yup, it looks like this is
On Wed, 2004-04-21 at 20:54, Rob Tanner wrote:
> Craig,
>
> I did a bit of googling, and I found a lot of complaints about RH not
> dumping core, but no one seems to know had to turn that limitation off.
> Have you any ideas?
>
> If nothing else, at least I've paid my bucks to RedHat so I shoul
After some tinkering, removing the IP address from /etc/hosts was the
magic bullet. However, this raises a larger question:
If S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP tells sendmail not to rewrite
the address (allegedly), why was it still doing it?
Probably a better question for another list, ho
Rob,
Took a while to figure out what to set so that core could get dumped. I
think this is what you're asking for:
(gdb) bt
#0 0xb7473127 in _sasl_ipfromstring (addr=0x1 bounds>, out=0x0, outlen=0)
at common.c:1658
#1 0xb7472140 in sasl_setprop (conn=0x806dfa8, propnum=1, value=0x1)
at commo
Craig,
I did a bit of googling, and I found a lot of complaints about RH not
dumping core, but no one seems to know had to turn that limitation off.
Have you any ideas?
If nothing else, at least I've paid my bucks to RedHat so I should be
able to ask them.
-- Rob
--On Friday, April 23, 2004
On Thu, 2004-04-22 at 11:54, Rob Tanner wrote:
> Craig,
>
> I did a bit of googling, and I found a lot of complaints about RH not
> dumping core, but no one seems to know had to turn that limitation off.
> Have you any ideas?
>
> If nothing else, at least I've paid my bucks to RedHat so I shou
Can you just delete/move the deliver.db and restart Cyrus? That is not a
critical database, considering that you are currently down.
Andy
On Thu, 22 Apr 2004, Nels Lindquist wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Our production Cyrus server is down; please CC rep
Christoph Moench-Tegeder wrote:
To solve this issue, each address must be split into username and
domain. I will write a patch as soon as we have migrated our
cyrus-1.5-environment to 2.2.
Here we go (patching deliver.c is easier than converting thousands
of filters):
diff -Nru cyrus-imapd-2.2.3.
On Wed, 2004-04-21 at 21:47, Rob Tanner wrote:
> Rob,
>
> I've included just the tail end of the strace confirming the segmentaion
> fault, but there was no corresponding core dump. Do I have to do something
> special to cause it to dump core?
Some versions of RH seem to set a core file size
--On Thursday, April 22, 2004 11:21:38 AM -0400 Rob Siemborski
<[EMAIL PROTECTED]> wrote:
On Thu, 22 Apr 2004, Moritz Both wrote:
It looks llike it may be related to re-entrace in the sasl libraries.
See this:
[snip]
The problem was that pam_ldap was compiled with sasl, and the sasl
libraries ar
I've configured both sendmail and cyrus to do both SMTP AUTH and LMTP
AUTH respectively. Delivery is done via LMTP TCP. The one thing not
working is the passing of the auth credentials from sendmail to lmtp.
I.e if I have a shared folder with a post acl assigned to user jsmith,
and jsmith sends
On Wed, 21 Apr 2004, Noll Janos wrote:
> Doest anyone have any ideas for the following problem?
Add a proper DBCONFIG file to the db/ directory, and increase (a lot) the
amount of memory available for the regions. Then, run db_recover to re-init
the DB environment.
For more data on this, see th
Rob Siemborski wrote:
On Tue, 20 Apr 2004, Sergio Devojno Bruder wrote:
output trace from what program in particular? mupdate? on FEs, on master
or on backends?
Specifically a protocol trace between the mupdate master and the
frontends.
-Rob
Sorry, but we made a workaround for this prob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Harms wrote:
After some tinkering, removing the IP address from /etc/hosts was the
magic bullet. However, this raises a larger question:
If S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP tells sendmail not to rewrite
the address (allegedly), why was it
Le mer 21/04/2004 à 21:38, Noll Janos a écrit :
>
> Apr 21 11:07:19 lmtpunix[16815]: DBERROR db4: Logging region out of
> memory; you may need to increase its size
I found something in the DB4 documentation:
int
DB_ENV->set_lg_regionmax(DB_ENV *dbenv, u_int32_t lg_regionm
Hi!
Le ven 23/04/2004 à 12:32, Craig Ringer a écrit :
> >
> > Apr 21 11:07:19 lmtpunix[16815]: DBERROR db4: Logging region out of
> > memory; you may need to increase its size
> > --
>
> If you can, I'd stop the master and then run db_verify on deliver.db. I
> wouldn't be sur
Hi folks I am trying to conf cyrus but the imap and pop are not running:
Apr 19 15:34:32 bh pop3d[96917]: KERBEROS_V4: can't access srvtab file
/etc/srvtab: No such file or directory
Apr 19 15:34:32 bh
pop3d[96917]:add_plugin(/usr/local/lib/sasl/libkerberos4.so) failed: generic
failure
Apr 19 15:3
Can you just delete/move the deliver.db and restart Cyrus? That is not a
critical database, considering that you are currently down.
Andy
On Thu, 22 Apr 2004, Nels Lindquist wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Our production Cyrus server is down; please CC repl
Christoph Moench-Tegeder wrote:
To solve this issue, each address must be split into username and
domain. I will write a patch as soon as we have migrated our
cyrus-1.5-environment to 2.2.
Here we go (patching deliver.c is easier than converting thousands
of filters):
diff -Nru cyrus-imapd-2.2.3.
Sorry, I failed to mention any relevant version information.
o Running on Redhat 6.2 (I know, I know) with ext2 fs. Should I have
done a "chattr +S" on the db files? The docs only mention user
quota, etc.
o Berkely DB 4.1.25, compiled from source
o Cyrus SASL 2.1.17
o Cyrus IMAPD 2.2.3
Again,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Our production Cyrus server is down; please CC replies directly to me
at "[EMAIL PROTECTED]" -- I can still get that mail, while my subscribed
address mailstore is on the affected server.
I tried a routine restart of our IMAP server this morning, bu
After some tinkering, removing the IP address from /etc/hosts was the
magic bullet. However, this raises a larger question:
If S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP tells sendmail not to rewrite
the address (allegedly), why was it still doing it?
Probably a better question for another list, ho
On Thu, 22 Apr 2004, Moritz Both wrote:
> It looks llike it may be related to re-entrace in the sasl libraries.
> See this:
[snip]
> The problem was that pam_ldap was compiled with sasl, and the sasl
> libraries are not reentrant. Thus a double free bug was triggered.
Yup, it looks like this is l
It looks llike it may be related to re-entrace in the sasl libraries.
See this:
http://bugs.debian.org/145766
I had seg faults on debian woody when I tried this: Cyrus imap -> sasl
-> pam -> pam_ldap
The problem was that pam_ldap was compiled with sasl, and the sasl
libraries are not reentran
29 matches
Mail list logo
