Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 328375 - mail-mta/postfix-2.6.7: postfix/local - "unknown mail transport error"
Summary: mail-mta/postfix-2.6.7: postfix/local - "unknown mail transport error"
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Net-Mail Packages
URL: http://serverfault.com/questions/1602...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-15 10:45 UTC by Kai Krakow
Modified: 2011-03-16 17:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
postfix/local backtrace (v2.6.6) (postfix-2.6.6-backtrace.txt,4.20 KB, text/plain)
2010-07-15 10:47 UTC, Kai Krakow
Details
output of postconf -n (v2.6.6) (postfix-2.6.6-main-cf.txt,2.91 KB, text/plain)
2010-07-15 10:49 UTC, Kai Krakow
Details
output of emerge --info (emerge-info.txt,5.09 KB, text/plain)
2010-07-15 10:52 UTC, Kai Krakow
Details
postfix/local backtrace (v2.6.6) (postfix-2.6.6-full-backtrace.txt,4.23 KB, text/plain)
2010-07-15 10:56 UTC, Kai Krakow
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Krakow 2010-07-15 10:45:06 UTC
The postfix/local daemon segfaults and produces an "unknown mail transport error" - thus mails to local system accounts are no longer deliverable. They just stick in the queue. However, virtual mail users with maildirs hosted locally via mysql on the same system are still receiving mails.

The system was upgraded from postfix 2.5.5 which ran stable with the same setup, to postfix 2.6.6 (currently stable in portage). I tried to go to keyworded 2.6.7 but still have the same problem.

Reproducible: Always

Actual Results:  
postfix/local segfaults, seemingly because user name expansion results in a null pointer

Expected Results:  
postfix/local should work like before and deliver mails to the local maildir in the system user's homedir.

I'll attach backtrace and configuration. The problem was already posted to the postfix-users mailing list. But it looks like 2.6.7 is already rather "old" (current stable is 2.7.x, 2.6 series is already "past stable"). I consider this critical as mails are deferred and then bounced when the retry timeout has expired. The mail is lost then.
Comment 1 Kai Krakow 2010-07-15 10:47:03 UTC
Created attachment 238871 [details]
postfix/local backtrace (v2.6.6)
Comment 2 Kai Krakow 2010-07-15 10:49:53 UTC
Created attachment 238873 [details]
output of postconf -n (v2.6.6)
Comment 3 Kai Krakow 2010-07-15 10:52:56 UTC
Created attachment 238875 [details]
output of emerge --info
Comment 4 Kai Krakow 2010-07-15 10:56:46 UTC
Created attachment 238877 [details]
postfix/local backtrace (v2.6.6)

Here's a more complete backtrace (generated with "bt full")
Comment 5 Kai Krakow 2010-07-21 18:00:12 UTC
Adding "-O2" to CFLAGS (an "-Ox" parameter was missing) solved the problem. Seems to be an GCC issue. I leave this bug open to let the experts handle how to solve this report. I don't know if setting "-O2" is mandatory, or if postfix should compile and work fine without this or with another optimizer level. Maybe the ebuild should just force "-O2" or other compatible optimizer levels.

If someone wants to debug this further: The pointer to the problem is within src/local/recipient.c:319 when the "state" struct is passed to deliver_switch(): Just before the call the struct members are set correct, then on entering the function, the members are reset to the original values on the stack when deliver_recipient() (the calling function) was entered (and thus state.msg_attr.local is reset to 0x0).
Comment 6 Kai Krakow 2010-07-21 20:00:25 UTC
Possibly related: http://bugs.gentoo.org/76512
Comment 7 Tim Harder gentoo-dev 2011-03-16 17:45:13 UTC
Is this still an issue with the 2.7.* or 2.8.* versions currently in the tree?
Comment 8 Kai Krakow 2011-03-16 17:51:37 UTC
I cannot try, since the affected system is a production system.

However, using "-O2" fixes the problem - probably using GCC4 may fix it, too. Originally, the system used GCC3. It has been converted to using GCC4 meanwhile since newer hardened-sources require it (compiling the kernel would result in a compilation error otherwise, and the kernel no longer officially supports GCC3).
Comment 9 Tim Harder gentoo-dev 2011-03-16 17:56:03 UTC
(In reply to comment #8)
> I cannot try, since the affected system is a production system.
> 
> However, using "-O2" fixes the problem - probably using GCC4 may fix it, too.
> Originally, the system used GCC3. It has been converted to using GCC4 meanwhile
> since newer hardened-sources require it (compiling the kernel would result in a
> compilation error otherwise, and the kernel no longer officially supports
> GCC3).

Ok, I think I'll mark this fixed since I can't reproduce it. Feel free to reopen it if you can reproduce the issue with GCC4 and any version of postfix in the tree. Thanks.