Bug 284391 - lmpt backends die before end of session
Summary: lmpt backends die before end of session
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-imapd
Version: 6
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Tomas Janousek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-10 09:28 UTC by Frank Wittig
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version: 2.3.9-7
Clone Of:
Environment:
Last Closed: 2007-10-09 10:49:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Frank Wittig 2007-09-10 09:28:45 UTC
Description of problem:

When postfix delivers mail to cyrus-imapd using deliver program it prematurely
dies ("...signaled to death by 6") just before the end of the session.

The result of this is that mails are correctly stored into users' mailboxes but
also remain inside postfix's queue with the remark "temporary failure".

The effect seems to be related to some user mailboxes since I have about 20
users on my server but only 2 of then seem to be affected.
I tried reconstructing the affected mailboxes without effect.

When switching from cyrus deliver to lmtp connections the same problem persists.
Then postfix queue remark for the affected mails is "deferred (lost connection
with 127.0.0.1[127.0.0.1] while sending end of data -- message may be sent more
than once)". This is for both unix sockets and TCP sockets.

The problem disappears after downgrading to 2.3.8-3. All "hanging" mails are
then successfully processed and removed from queue as expected.


Version-Release number of selected component (if applicable):

cyrus-imapd-2.3.9-6.fc6


How reproducible:

Upgrade to cyrus-imapd-2.3.9-6.fc6


Actual results:

Some mail keep inside Postfix queue because cyrus delivery backend terminates
prematurely.


Expected results:

Mails should be removed from queue after cyrus successfully deliverd them into
users' mailboxes.


Additional info:

Sep  3 16:41:21 nazgul lmtpunix[9664]: accepted connection
Sep  3 16:41:21 nazgul lmtpunix[9664]: lmtp connection preauth'd as postman
Sep  3 16:41:21 nazgul lmtpunix[9664]: duplicate_check:
<20070903144119.GB2284>     user.xxx          0
Sep  3 16:41:21 nazgul lmtpunix[9664]: duplicate_check:
<20070903144119.GB2284>     user.xxx          0
Sep  3 16:41:21 nazgul lmtpunix[9664]: mystore: starting txn 2147483867
Sep  3 16:41:21 nazgul lmtpunix[9664]: mystore: committing txn 2147483867
Sep  3 16:41:21 nazgul lmtpunix[9664]: duplicate_mark:
<20070903144119.GB2284>     user.xxx          1188830481 18424
Sep  3 16:41:21 nazgul lmtpunix[9664]: Delivered:
<20070903144119.GB2284> to mailbox: user.xxx
Sep  3 16:41:21 nazgul master[7165]: process 9664 exited, signaled to death by 6
Sep  3 16:41:21 nazgul master[7165]: service lmtpunix pid 9664 in BUSY state:
terminated abnormally
Sep  3 16:41:21 nazgul postfix/pipe[9804]: AF402BC: to=<xxx>,
orig_to=<xxx>, relay=cyrus, delay=0.14, delays=0.05/0.01/0/0.09,
dsn=4.3.0, status=deferred (temporary failure)

Comment 1 Tomas Janousek 2007-09-24 16:13:39 UTC
Sorry for the late reply. I tried to reproduce this but did not succeed. I
applied a few patches and made a new build, so you can try this one:
http://koji.fedoraproject.org/koji/taskinfo?taskID=170944
I don't think it will
help though.
I'd be glad if you can provide me a gdb backtrace. Use `socat STDIO
UNIX:/var/lib/imap/socket/lmtp` to connect to the lmtp socket, then use netstat
-pn to find the process you're connected to
and attach gdb using `gdb /usr/lib/cyrus-imapd/lmtpd pid', type 'c' into the gdb
prompt to resume the program. Then type something like this into the socat:

MAIL FROM:<test>
RCPT TO:<test01@localhost>
DATA
Subject: test

test
.
(don't forget the ".", and it should reply with a "250 something")
If it crashes, you should be able to print a backtrace using "bt full" at the
gdb prompt.

Don't forget to install the debuginfo package.

Comment 2 Frank Wittig 2007-10-04 10:43:23 UTC
I noticed the new 2.3.9-7 version in repository. Since I didn't had time yet to
test the above explained procedure I'll give it a try.
If the problem still persists I'll be back soon with - hopefully - valuable
debug information.

Comment 3 Frank Wittig 2007-10-09 08:47:18 UTC
After updating to 2.3.9-7 the problem disappeared.

Comment 4 Tomas Janousek 2007-10-09 10:49:56 UTC
Ok, let's call it fixed. :)


Note You need to log in before you can comment on or make changes to this bug.