t;>> cyr_expire[96599]: expunged 4907 out of 109443 messages from 143
>>>> mailboxes
>>>> master[833]: process 96599 exited, signaled to death by 11
>>> It would be great to see a traceback.
>>
>> Also your imapd.conf. In particular: is delayed
gt;>> cyr_expire [96599]: Expunged 3005 messages from user.myuser.Trash
>>> cyr_expire[96599]: expunged 4907 out of 109443 messages from 143
>>> mailboxes
>>> master[833]: process 96599 exited, signaled to death by 11
>> It would be great to see a traceback.
5 messages from user.myuser.Trash
> > cyr_expire[96599]: expunged 4907 out of 109443 messages from 143
> > mailboxes
> > master[833]: process 96599 exited, signaled to death by 11
>
> It would be great to see a traceback.
Also your imapd.conf. In particular: is delay
33]: process 96599 exited, signaled to death by 11
>
> --per
>
> 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
>
I got many of that messages after a
lboxes
> master[833]: process 96599 exited, signaled to death by 11
Probably a corrupt cyrus.cache file (at least that's the cause when I see
these). Try reconstruct on the mailbox.
--
David Carter Email: [EMAIL PROTECTED]
University Computing Service,
messages from 143
> mailboxes
> master[833]: process 96599 exited, signaled to death by 11
It would be great to see a traceback.
:wes
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
No idea why, comments anyone? A limitation of some sort when expunging a
lot of messages?
cyr_expire [96599]: Expunged 3005 messages from user.myuser.Trash
cyr_expire[96599]: expunged 4907 out of 109443 messages from 143 mailboxes
master[833]: process 96599 exited, signaled to death by 11
--per
rus/imaplocalhost[19389]: accepted connection
Dec 16 15:02:07 pascacio master[19369]: process 19389 exited, signaled
to death by 11
Dec 16 15:02:07 pascacio master[19369]: service imaplocalhost pid
19389 in BUSY state: terminated abnormally
This are the contests of /tmp/gdb-backtrace.cyrus.imapd
cacio cyrus/imaplocalhost[19389]: accepted connection
Dec 16 15:02:07 pascacio master[19369]: process 19389 exited, signaled
to death by 11
Dec 16 15:02:07 pascacio master[19369]: service imaplocalhost pid 19389
in BUSY state: terminated abnormally
This are the contests of /tmp/gdb-backtrace.cy
hi
i m using cyrus2.3.6 on a RHEL4 server
the mail is delivered from a postfix server via lmtp
from time to time i got that kind of message on the postfix side
Nov 3 08:32:12 sodome postfix/lmtp[30982]: 021B618D6F6:
to=<[EMAIL PROTECTED]
nt-evry.fr>, orig_to=<[EMAIL PROTECTED]>,
relay=molure
d my patch
*should* fix both problems.
On Oct 24, 2005, at 9:08 AM, Ken Murchison wrote:
Patrick Radtke wrote:
Several times an hour, our mupdate process on the murder master
dies.
Oct 19 07:12:41 notdog master[2277]: process 15588 exited,
signaled to death by 11
Oct 19 07:25:41 not
dies.
Oct 19 07:12:41 notdog master[2277]: process 15588 exited, signaled
to death by 11
Oct 19 07:25:41 notdog master[2277]: process 16681 exited, signaled
to death by 11
Oct 19 07:32:41 notdog master[2277]: process 17644 exited, signaled
to death by 11
Oct 19 07:49:40 notdog master[2277]: pr
times an hour, our mupdate process on the murder master dies.
Oct 19 07:12:41 notdog master[2277]: process 15588 exited,
signaled to death by 11
Oct 19 07:25:41 notdog master[2277]: process 16681 exited,
signaled to death by 11
Oct 19 07:32:41 notdog master[2277]: process 17644 exited,
sig
Patrick Radtke wrote:
Several times an hour, our mupdate process on the murder master dies.
Oct 19 07:12:41 notdog master[2277]: process 15588 exited, signaled to
death by 11
Oct 19 07:25:41 notdog master[2277]: process 16681 exited, signaled to
death by 11
Oct 19 07:32:41 notdog master
Several times an hour, our mupdate process on the murder master dies.
Oct 19 07:12:41 notdog master[2277]: process 15588 exited, signaled
to death by 11
Oct 19 07:25:41 notdog master[2277]: process 16681 exited, signaled
to death by 11
Oct 19 07:32:41 notdog master[2277]: process 17644
conf.
> Then, you could try starting master with something like strace -f or
> whatever is apropriate for your OS.
>
> Simon
>
>
>
>> Error:
>> Jun 17 20:12:30 andromeda master[31404]: process 31410 exited, signaled
>> to death by 11
>> Jun 17 20:12:30 andromeda
Günter Zimmermann wrote:
Hi people,
The problem is solved.
It was because of different versions od berkley-db in sasl and imapd.
It found this information in the trace.
Another Point is that its only works with berkley-db version 4.1.25.
Version 4.2.52 did not work.
We use 4.2.52. Had major slowdo
> What your database backends configuration? you could provide us a diff
> between your 2.2.2beta imapd.conf and the 2.2.5 imapd.conf.
> Then, you could try starting master with something like strace -f or
> whatever is apropriate for your OS.
>
> Simon
>
>
>
>>
andromeda master[31404]: process 31410 exited, signaled
> to death by 11
> Jun 17 20:12:30 andromeda master[31404]: service imap pid 31410 in BUSY
> state: terminated abnormally
>
> I compiled with this command:
> make clean;
> ./configure \
> --prefix=/opt/cyrus-imapd-2.
andromeda master[31404]: process 31410 exited, signaled
to death by 11
Jun 17 20:12:30 andromeda master[31404]: service imap pid 31410 in BUSY
state: terminated abnormally
I compiled with this command:
make clean;
./configure \
--prefix=/opt/cyrus-imapd-2.2.5 \
--sysconfdir=/etc/cyrus-imapd-2.2.5
I think the problem is related to the cyrus.* files. It seems that a
lot of the users having problems and causing the signaled to death by 11
errors have cyrus.*.NEW files. What would cause the .NEW files to
remain? A reconstruct seems to fix the problem, but anyone know what
may be causing
1185]: [ID 970914 local6.error] process
21886 exited, signaled to death by 11
Jun 1 08:43:26 cyrus master[21185]: [ID 970914 local6.error] process
20660 exited, signaled to death by 11
Jun 1 08:43:43 cyrus master[21185]: [ID 970914 local6.error] process
20133 exited, signaled to death by 11
Jun
After the upgrade to Cyrus IMAP 2.2.5 (SASL 2.1.18), I've been seeing a
lot of these errors in the logs:
Jun 1 08:42:19 cyrus master[21185]: [ID 970914 local6.error] process
21886 exited, signaled to death by 11
Jun 1 08:43:26 cyrus master[21185]: [ID 970914 local6.error] process
Okay, I just realized that I ought to come back and post my mistakes here
because searching google had been no help to me (and it was simple logic
that solved my problem):
You have to make sure that the mailboxes for the account have been created.
I was trying to login to sieveshell as root, but h
Well, it looks like enough poking around (and some updating) has fixed the
authentication problem. But I am still having issues with launching
sieveshell. The problem is that timsieved is "signaled to death by 11".
The only references to this error that I could find where in relati
On Wed, 26 Mar 2003, Jeremy Rumpf wrote:
> Actually, I think someone a while ago had come up with a solution. I'm not
> sure how proper it is, you can decide. Here's a copy of the post from Fritz
> Test <[EMAIL PROTECTED]> :
[snip]
Hmmm, I probably should have looked at it then... but I don't thi
On Wednesday 26 March 2003 08:57 am, Oliver Pitzeier wrote:
> Jeremy Rumpf wrote:
> > This has been on this list in the past, this post is on an
> > older release, but is the problem is the same. The imap server
> > dumps when a message from Outlook or Outlook Express is copied
> > to it. Machine i
Jeremy Rumpf wrote:
> This has been on this list in the past, this post is on an
> older release, but is the problem is the same. The imap server
> dumps when a message from Outlook or Outlook Express is copied
> to it. Machine is an older alpha ev5.6. Here's a recap:
[ ... ]
Thanks a lot Jeremy
stalling cyrus, by attempting to copy all my local messages to cyrus imapd
by dragging them from the local inbox to the imap inbox on cyrus. In doing
so, Outlook opens an error box stating, "You message could not be uploaded to
the imap server. The server refused to accept it". Th
Oliver Pitzeier wrote:
> Now I'll dig into tmcomp(atmp, btmp) :-)
OK... I solved the problem... It's not OK to do it this way - I know, but it
actually helps for the moment...
--- mkgmtime.c.orig Wed Mar 26 14:03:34 2003
+++ mkgmtime.c Wed Mar 26 14:04:19 2003
@@ -100,6 +100,8 @@
{
> In <[EMAIL PROTECTED]>
> Christian Schulte <[EMAIL PROTECTED]> wrote:
> Oliver Pitzeier wrote:
[...]
> Hhm! No real answers to my questions for now... I now know how to debug
> a cyrus installation but I really need to know how to upgrade from db3.2
> to db4.1 !
Do ./configure --
Oliver Pitzeier wrote:
> > Rob Siemborski wrote:
> > > > Copying mails between two imap-servers is normally no
> > > > problem and works with all my servers, except this one...
> > > >
> > > > Any ideas?
> > >
> > > Do you have a protocol trace of what outlook is feeding cyrus?
> > > Alternative
Oliver Pitzeier wrote:
Hi volks!
I thankfull for ANY help!
I'm currently debugging a signal 11 problem... I located it in getdatetime
(imapd.c) and have to trace it down to the final "killer line" I'm working
on an Compaq Alpha DS10...
If anyone has similar problems, or if any developer can
Rob Siemborski wrote:
> > Here some stuff I logged via syslog:
> > Mar 25 16:34:29 mail imapd[14859]: tm.tm_mday: 25
> > Mar 25 16:34:29 mail imapd[14859]: tm.tm_mon: 2
> > Mar 25 16:34:29 mail imapd[14859]: month: mar
> > Mar 25 16:34:30 mail imapd[14859]: year: 103
> > Mar 25 16:34:30 mail imapd[
> Rob Siemborski wrote:
> > > Copying mails between two imap-servers is normally no problem and
> > > works with all my servers, except this one...
> > >
> > > Any ideas?
> >
> > Do you have a protocol trace of what outlook is feeding
> > cyrus? Alternatively, do you have a backtrace of the core d
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> Here some stuff I logged via syslog:
> Mar 25 16:34:29 mail imapd[14859]: tm.tm_mday: 25
> Mar 25 16:34:29 mail imapd[14859]: tm.tm_mon: 2
> Mar 25 16:34:29 mail imapd[14859]: month: mar
> Mar 25 16:34:30 mail imapd[14859]: year: 103
> Mar 25 16:34:30
Rob Siemborski wrote:
> > is invoked it dies... You can also said syslog(LOG_ERR, dir) and it
> > will also die. So it seems for me, that it has something to do with
> > "dir", which is a "register int"...
>
> This isn't terribly surprising, since syslog is expecting a
> const char * as its sec
Rob Siemborski wrote:
> > Copying mails between two imap-servers is normally no problem and
> > works with all my servers, except this one...
> >
> > Any ideas?
>
> Do you have a protocol trace of what outlook is feeding
> cyrus? Alternatively, do you have a backtrace of the core dump?
No, I ha
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> is invoked it dies... You can also said syslog(LOG_ERR, dir) and it will also
> die. So it seems for me, that it has something to do with "dir", which is a
> "register int"...
This isn't terribly surprising, since syslog is expecting a const char *
as
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> OK. Kick my ass for this now... :-(
>
> I tried to copy some mails from one imap server to this new one (using Outlook
> XP and Outlook Express 6)... This is where the error occurs...
>
> BUT(!): I tried it now with Evolution; I copied the same mail. I
Henrique de Moraes Holschuh wrote:
[ ... ]
> > I tried to copy some mails from one imap server to this new
> > one (using
> > Outlook XP and Outlook Express 6)... This is where the
> > error occurs...
>
> It is still a real bug. Cyrus should be resilient to fucked
> up input data (as long as y
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> > > I'm currently debugging a signal 11 problem... I located it
> > > in getdatetime
> > > (imapd.c) and have to trace it down to the final "killer
> > > line" I'm working on an Compaq Alpha DS10...
> > >
> > > Version of cyrus-imapd 2.1.12.
>
>
[ ... ]
> > I'm currently debugging a signal 11 problem... I located it
> > in getdatetime
> > (imapd.c) and have to trace it down to the final "killer
> > line" I'm working on an Compaq Alpha DS10...
> >
> > If anyone has similar problems, or if any developer can help
> > me trace it down...
[ ... ]
> I'm currently debugging a signal 11 problem... I located it
> in getdatetime
> (imapd.c) and have to trace it down to the final "killer
> line" I'm working on an Compaq Alpha DS10...
>
> If anyone has similar problems, or if any developer can help
> me trace it down I'd be
Hi volks!
I thankfull for ANY help!
I'm currently debugging a signal 11 problem... I located it in getdatetime
(imapd.c) and have to trace it down to the final "killer line" I'm working
on an Compaq Alpha DS10...
If anyone has similar problems, or if any developer can help me trace it
down..
Hi,
On a new server, I was hit by a 'signaled to death by 11' problem
recently. Logs looked like this:
Jan 15 00:11:27 imapd[13435]: open: user xxeid opened INBOX
Jan 15 00:11:27 master[1838]: process 13435 exited, signaled to
death by 11
Jan 15 00:11:27 imapd[13617]
Rob:
> DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it
> needs the plaintext password (or DIGEST secret). (i.e. it won't work with
> saslauthd).
This is making since - Thanks. I'm assuming that the auxprop plugin method
doesn't use PAM and thus the LDAP authentication
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> > DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it
> > needs the plaintext password (or DIGEST secret). (i.e. it won't work with
> > saslauthd).
>
> This is making since - Thanks. I'm assuming that the auxprop plugin method
>
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> Okay. Then what plugin is expected to perform LDAP authentication?
No plugins supplied by the Cyrus SASL Distribution currently perform LDAP
authentication.
There is one third-party auxprop plugin that we're looking at including in
the distribution
Okay. Then what plugin is expected to perform LDAP authentication?
RB
> Every plugin that supports a client-side SASL negotiation should export
> this (which is basically all of the included ones, except for libsasldb).
> -Rob
Also, have any idea what is causing the following error?
unable to get entry point sasl_client_plug_init in
/usr/lib/sasl/libsasldb.so:
/usr/local/lib/libsasl.so.7: undefined symbol: sasl_client_plug_init
RB
> Every plugin that supports a client-side SASL negotiation should ex
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> Interesting. Have any ideas of what SASL V2 library the module
> "sasl_client_plug_init"
> resides? I look via "nm" and "ar" and found nothing.
Every plugin that supports a client-side SASL negotiation should export
this (which is basically all o
Ken:
>>Just to insure that Cyrus IMAP
>> was not
>> experiencing the same bdb issue as SASL V2, I recompiled IMAP 2.1.3 -
here
>> are the
>> "configure script" options selected ->
>>
>> ./configure \
>> --enable-fulldirhash \
>> --with-sasl=/usr/lib/sasl2 \
>> --wi
OCNS Consulting wrote:
>
> Ken:
>
> I finally determined the issue with BerkeleyDB. The SASL configure script
> looks for "/usr/include/db3" which is found and contains (as expected) bdb3
> headers. Of course I compile SASL against bdb4 which is specified by
> including
> the options ->
>
>
Ken:
I finally determined the issue with BerkeleyDB. The SASL configure script
looks for "/usr/include/db3" which is found and contains (as expected) bdb3
headers. Of course I compile SASL against bdb4 which is specified by
including
the options ->
--with-bdb-libdir=/usr/local/BerkeleyDB
u know of a more exact method to obtain the traceback information,
please forward.
Thanks for your assistance.
RB
-Original Message-
From: Rob Siemborski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 21, 2002 10:44 AM
To: OCNS Consulting
Cc: Ken Murchison
Subject: RE: Signaled to Death by 1
_end=0xbfffedec) at
../sysdeps/generic/libc-start.c:129
(gdb)
-Original Message-
From: Ken Murchison [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 21, 2002 9:45 AM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again - bdb issue?
OCNS Consulting wrot
ink
the binaries.
Ken
> -Original Message-
> From: Ken Murchison [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 7:54 PM
> To: OCNS Consulting
> Cc: [EMAIL PROTECTED]
> Subject: Re: Signaled to Death by 11 - Again - bdb issue?
>
> In your debugger outputs,
20, 2002 7:54 PM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again - bdb issue?
In your debugger outputs, both lib/libdb-4.0.so and /usr/lib/libdb.so.3
are being loaded. What is /usr/lib/libdb.so.3? Is this a BDB 3.x
library? If so, this is probably your
one.
> Loaded symbols for /usr/lib/libdb.so.3
> #0 0x in ?? ()
> (gdb) bt
> #0 0x in ?? ()
> #1 0x08048bf0 in ?? ()
> #2 0x08048c84 in ?? ()
> #3 0x08048fd0 in ?? ()
> #4 0x40102627 in __libc_start_main (main=0x8048ee0, argc=3,
> ubp_av=0xb1f4, i
-Original Message-
From: Ken Murchison [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 5:16 PM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again -
Are you _sure_ that SASL and IMAP and linked against the same version of
BDB? Do a 'ldd /us
Are you _sure_ that SASL and IMAP and linked against the same version of
BDB? Do a 'ldd /usr/cyrus/bin/imapd' and make sure you're not linked
against multiple versions of BDB.
Was the /etc/sasldb2 file created with the same version?
OCNS Consulting wrote:
>
> Ken:
>
> Here's the traceback r
Ken:
Here's the traceback results you requested.
Let me know how I can help
RB
=
# gdb -core=core -e /usr/cyrus/bin/imapd
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is
You need to feed the binary into gdb as well. Try something like:
gdb /usr/cyrus/bin/imapd
Ken
OCNS Consulting wrote:
>
> Ken:
>
> As per your request, below is the traceback from a core file generated by
> "imapd"
> causing the "signaled by death 11" error.
>
> I look forward to your re
Ken:
As per your request, below is the traceback from a core file generated by
"imapd"
causing the "signaled by death 11" error.
I look forward to your response.
RB
==
# gdb -core=core
GNU gdb Red Hat Linux (5.1-1)
C
My idea about cyrus getting sig11'ed is because of berkeley DB.
log file excerpt (SA
> B4):
>
>Mar 19 10:50:11 mailsrv imapd[24376]: accepted connection
>Mar 19 10:50:11 mailsrv master[24388]: about to exec /usr/cyrus/bin/imapd
>Mar 19 10:50:11 mailsrv imap[24388]: executed
>Mar 19 10:50:11 mailsrv master[24347]: process 24376 exite
24376]: accepted connection
Mar 19 10:50:11 mailsrv master[24388]: about to exec /usr/cyrus/bin/imapd
Mar 19 10:50:11 mailsrv imap[24388]: executed
Mar 19 10:50:11 mailsrv master[24347]: process 24376 exited, signaled to
death by 11
As per Ken Murchison's suggestion, I looked for a cor
>>Anything look familiar or obvious? Suggestions?
Look familiar, anyway. It looks like the inevitable SASL reentrancy
problem. Try rebuilding your LDAP libs --without-sasl and then linking
pam_ldap to the new libs.
>>Anything look familiar or obvious? Suggestions?
Familiar, anyway. Looks like the old SASL re-entrancy problem to be. Try
rebuilding your OpenLDAP libs --without-sasl and linking pam_ldap to them.
sieve, etc...)
>
> When a NEW session is attempted, authentication appears to work, imapd
> is called and then "signaled to death by 11" occurs. Here's a LOG excerpt.
>
> Mar 18 17:00:07 mailsvr imapd[12741]: accepted connection
> Mar 18 17:00:07 mai
appears to start correctly along with all supporting
protocols (imap, imaps, pop3, pop3s, sieve, etc...)
When a NEW session is attempted, authentication appears to work, imapd
is called and then "signaled to death by 11" occurs. Here's a LOG excerpt.
Mar 18 17:00:07 mail
ke my rpm-spec files for sasl and imap, I will be glad to
post them or send them directly.
Vernon Fort
-Original Message-
From: Vernon A.. Fort
Sent: Thursday, January 31, 2002 3:49 PM
To: [EMAIL PROTECTED]
Subject: RE: Signaled to Death by 11
I had another thought.
1.
ke my rpm-spec files for sasl and imap, I will be glad to
post them or send them directly.
Vernon Fort
-Original Message-
From: Vernon A.. Fort
Sent: Thursday, January 31, 2002 3:49 PM
To: [EMAIL PROTECTED]
Subject: RE: Signaled to Death by 11
I had another thought.
1.
Hi,
We see this problem occasionally on our 2.0.16 servers:
Jan 28 22:42:58 mailhub.acsu.buffalo.edu master[3279]: [ID 970914 local6.error]
process 294 exited, signaled to death by 11
Jan 28 22:43:01 mailhub.acsu.buffalo.edu quota[1]: [ID 866726 local6.error]
DBERROR db3: 2 lockers
Jan
:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:55 PM
To: Vernon A.. Fort; [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11
Just a shot in the dark, but is Postfix using
Berkeley DB for anything?
LMTP is shared among both applications and if
either needs to access the same DB then one
the problem do to all the posts I see concerning the vm stuff.
Any thoughts.
Vernon A. Fort
-Original Message-
From: Michael Fair [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:55 PM
To: Vernon A.. Fort; [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11
Just a shot
Berkely version?
-- Michael --
- Original Message -
From: "Vernon A.. Fort" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 25, 2002 10:14 AM
Subject: Signaled to Death by 11
> Hello all,
> I have a problem for which has consumed me. The mas
ed to Death by 11":
Subject: Signaled to Death by 11
Date sent: Fri, 25 Jan 2002 12:14:27 -0600
From: "Vernon A.. Fort" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
} Hello all,
} I have a problem for wh
Hello all,
I have a problem for which has consumed me. The master process is reporting the
following:
Jan 25 09:58:33 mail master[8412]: process 18150 exited, signaled to death by
11
What I have done:
1. Re-compiled both cyrus-sasl and cyrus-imap using db3
?)
*
* Nov 15 20:16:26 firewall master[3415]: process 3419 exited, status 0
* Nov 15 20:16:29 firewall master[3422]: about to exec
* /usr/cyrus/bin/imapd
* Nov 15 20:16:29 firewall service-imapd[3422]: executed
* Nov 15 20:16:29 firewall master[3415]: process 3422 exited, signaled to
* death by 11
Nov 15 20:16:29 firewall master[3422]: about to exec
/usr/cyrus/bin/imapd
Nov 15 20:16:29 firewall service-imapd[3422]: executed
Nov 15 20:16:29 firewall master[3415]: process 3422 exited, signaled to
death by 11
gruß
Fred
Lawrence Greenfield wrote:
>
>Date: Mon, 1 Oct 2001 11:00:22 +0200
>From: Szymon Juraszczyk <[EMAIL PROTECTED]>
>
> I just changed
>
>sprintf
>(messageToSend,"%s\n%s\n%s\n%s\n%s\n",class,instance,user,mailbox,message);
>
> to
>
>sprintf (messageToSend,"%s\
Date: Mon, 1 Oct 2001 11:00:22 +0200
From: Szymon Juraszczyk <[EMAIL PROTECTED]>
I just changed
sprintf
(messageToSend,"%s\n%s\n%s\n%s\n%s\n",class,instance,user,mailbox,message);
to
sprintf (messageToSend,"%s\n%s\n%s\n%s\n",class,instance,user,mailbox);
On Mon, 2001-10-01 at 17:27:58, Jeremy Howard wrote:
> Szymon Juraszczyk wrote:
> > OK, do not worry :-) We learn something each day. I had no sleep, it was
> > already dawn so I wrote some sharp words. Thanks for contributing the
> > software anyway!
> >
> Can you post the patch that you made
Szymon Juraszczyk wrote:
> OK, do not worry :-) We learn something each day. I had no sleep, it was
> already dawn so I wrote some sharp words. Thanks for contributing the
> software anyway!
>
Can you post the patch that you made please? Any other suggestions for
improving unix_notify? I haven't
On Mon, 2001-10-01 at 15:04:59, Jeremy Howard wrote:
> Amos Gouaux wrote:
> > > On Mon, 1 Oct 2001 05:56:08 +0200,
> > > Szymon Juraszczyk <[EMAIL PROTECTED]> (sj) writes:
> >
> > sj> I spent a few days figuring out why this beast was crashing. And all
> > sj> because lots of people sti
On Sun, 2001-09-30 at 23:25:37, Amos Gouaux wrote:
> > On Mon, 1 Oct 2001 05:56:08 +0200,
> > Szymon Juraszczyk <[EMAIL PROTECTED]> (sj) writes:
>
> sj> I spent a few days figuring out why this beast was crashing. And all
> sj> because lots of people still are unaware of elementary sec
Amos Gouaux wrote:
> > On Mon, 1 Oct 2001 05:56:08 +0200,
> > Szymon Juraszczyk <[EMAIL PROTECTED]> (sj) writes:
>
> sj> I spent a few days figuring out why this beast was crashing. And all
> sj> because lots of people still are unaware of elementary secure
programing
> sj> issues, hence
> On Mon, 1 Oct 2001 05:56:08 +0200,
> Szymon Juraszczyk <[EMAIL PROTECTED]> (sj) writes:
sj> I spent a few days figuring out why this beast was crashing. And all
sj> because lots of people still are unaware of elementary secure programing
sj> issues, hence they make trivial mistakes su
On Mon, 2001-10-01 at 04:57:14, Gerald Goebel wrote:
> > Sorry guys for replying to my own message twice, but I've got more
> > exciting news and updated information about the bug. The problem is not big
> > header in general, but big 'To:' field (and possibly others). Yes, it
> > happens that
Szymon Juraszczyk wrote:
>
> On Mon, 2001-10-01 at 04:02:52, Szymon Juraszczyk wrote:
>
> > On Sun, 2001-09-30 at 23:30:38, Szymon Juraszczyk wrote:
> >
> > > On Sun, 2001-09-30 at 17:04:34, Tarjei Huse wrote:
> > >
> > > > > Are you using PAM/LDAP? If so check the recent archives (about 4 weeks
On Mon, 2001-10-01 at 04:02:52, Szymon Juraszczyk wrote:
> On Sun, 2001-09-30 at 23:30:38, Szymon Juraszczyk wrote:
>
> > On Sun, 2001-09-30 at 17:04:34, Tarjei Huse wrote:
> >
> > > > Are you using PAM/LDAP? If so check the recent archives (about 4 weeks ago)
> > > > for a very long thread reg
On Sun, 2001-09-30 at 23:30:38, Szymon Juraszczyk wrote:
> On Sun, 2001-09-30 at 17:04:34, Tarjei Huse wrote:
>
> > > Are you using PAM/LDAP? If so check the recent archives (about 4 weeks ago)
> > > for a very long thread regarding a memory allocation problem between
> > > OpenLDAP and Cyrus. I
On Sun, 2001-09-30 at 17:04:34, Tarjei Huse wrote:
> > Are you using PAM/LDAP? If so check the recent archives (about 4 weeks ago)
> > for a very long thread regarding a memory allocation problem between
> > OpenLDAP and Cyrus. I'm not sure what the resolution was in the end... Using
> > saslauth
On Sat, 2001-09-29 at 13:44:49, Jeremy Howard wrote:
> > I experience often lmtpd process segfaulting with signal 11. I tried to
> > find a solution in the archivers the list, unfortunately with no luck.
> > What's strange is that sometimes it delivers the mail, the other time it
> > crashes, s
> Are you using PAM/LDAP? If so check the recent archives (about 4 weeks ago)
> for a very long thread regarding a memory allocation problem between
> OpenLDAP and Cyrus. I'm not sure what the resolution was in the end... Using
> saslauthd from the new SASL version would almost certainly fix it th
> I experience often lmtpd process segfaulting with signal 11. I tried to
> find a solution in the archivers the list, unfortunately with no luck.
> What's strange is that sometimes it delivers the mail, the other time it
> crashes, so deliver returns error 75 (temporary unavailable, try again).
Hi,
I experience often lmtpd process segfaulting with signal 11. I tried to
find a solution in the archivers the list, unfortunately with no luck.
What's strange is that sometimes it delivers the mail, the other time it
crashes, so deliver returns error 75 (temporary unavailable, try again).
On Mon, Aug 06, 2001 at 02:03:20PM -0400, [EMAIL PROTECTED] wrote:
> On a related note, different versions of Berkley DB versions
> on RH systems were resulting in signal 11 death problems
> earlier. A simple "ldd" check on the imapd built, will reveal
> these problems.
Not neccessarily. If the
1 - 100 of 135 matches
Mail list logo
