Bug 284391 - lmpt backends die before end of session
lmpt backends die before end of session
Product: Fedora
Classification: Fedora
Component: cyrus-imapd (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Janousek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-09-10 05:28 EDT by Frank Wittig
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version: 2.3.9-7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-09 06:49:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Frank Wittig 2007-09-10 05:28:45 EDT
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[] 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):


How reproducible:

Upgrade to cyrus-imapd-2.3.9-6.fc6

Actual results:

Some mail keep inside Postfix queue because cyrus delivery backend terminates

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@weisshuhn.de>     user.xxx          0
Sep  3 16:41:21 nazgul lmtpunix[9664]: duplicate_check:
<20070903144119.GB2284@weisshuhn.de>     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@weisshuhn.de>     user.xxx          1188830481 18424
Sep  3 16:41:21 nazgul lmtpunix[9664]: Delivered:
<20070903144119.GB2284@weisshuhn.de> 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@weisshuhn.de>,
orig_to=<xxx@weisshuhn.de>, 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 12:13:39 EDT
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:
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@example.com>
RCPT TO:<test01@localhost>
Subject: 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 06:43:23 EDT
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 04:47:18 EDT
After updating to 2.3.9-7 the problem disappeared.
Comment 4 Tomas Janousek 2007-10-09 06:49:56 EDT
Ok, let's call it fixed. :)

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