Bug 118234

Just tried to build and install a postfix v2.1.18 RPM under Redhat v9,
and then install that RPM under RHEL3. It made no difference, the
error persisted.

Just installed postfix on a second machine, again with the same config
file. This second machine is showing the exact same problem:

Mar 14 13:43:41 samantha postfix/master[6192]: warning: process
/usr/libexec/postfix/cleanup pid 6197 killed by signal 11
Mar 14 13:43:41 samantha postfix/master[6192]: warning:
/usr/libexec/postfix/cleanup: bad command startup -- throttling
Mar 14 13:44:41 samantha postfix/master[6192]: warning: process
/usr/libexec/postfix/cleanup pid 6207 killed by signal 11
Mar 14 13:44:41 samantha postfix/master[6192]: warning:
/usr/libexec/postfix/cleanup: bad command startup -- throttling
Mar 14 13:45:42 samantha postfix/master[6192]: warning: process
/usr/libexec/postfix/cleanup pid 6218 killed by signal 11

The first machine is in the process of having a kernel built on it to
stress test the hardware with make -j bzImage. So far it's a good hour
into the compile and no errors so far, so it looks to not be a
hardware problem.

Created attachment 98523 [details]
Backtrace of segfault from xxgdb

Managed to get a backtrace from the segfault.

The code bombs out inside SASL, but it is not clear as to whether SASL is at
fault, LDAP is at fault, or Postfix is at fault.

From the postfix-users list:

>>[root@dungeon root]# ldd `postconf -h daemon_directory`/cleanup
>>          libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7584000)
>> [root@dungeon root]# ldd /usr/lib/libldap.so.2
>>          libsasl.so.7 => /usr/lib/libsasl.so.7 (0xb75b8000)
>They are linked against diffrent versions of Cyrus-SASL. This is bad!

Turns out Postfix is linked to SASL2, while OpenLDAP is linked to SASL1.

In addition, there are links to a library called libcom_err, which is
linked to v2 (e2fsprogs) and v3 (krb5-libs) at the same time.

Please can you organise fixes as soon as possible!

This has already been fixed and scheduled for release in U2. It is a
duplicate of bug 111767. In the interim you may ftp the U2 RPM here:

ftp://people.redhat.com/jdennis/postfix-2.0.16-13.RHEL3.i386.rpm

*** This bug has been marked as a duplicate of 111767 ***

I'm trying to figure out if we have a bug in our bugzilla, when I got
this bug report it was filed against RHEL3 U2. But we haven't released
U2, its not even in beta yet, and this bug is fixed in U2. Did you
specifically file this against RHEL3 U2? That should not have been
possible. What release did you file this bug against?

Changing product and version.

Aaargh! I spent a day hunting down this bug, and it's already been 
found and fixed - looking on bugzilla was one of the first things I 
did.

Is it possible to get bugzilla to be able to search all reports from 
a specific release onwards, eg "all bugs in postfix from RHEL3 
onwards"? (Unless it already does that, and the Problem is Between 
Chair and Keyboard).

I filed the bug against RHEL v3.0 update 1 - it was available from 
the dropdown list.

One more thing - is it possible to include the bug number of the 
duplicate? I need to know exactly how the problem was solved - by 
linking to SASL 1, or to SASL2, or to something else. I have built 
v2.0.18 from an independant rpm (from www.wl0.org), and would like to 
keep as close as possible to the environment that will exist in the 
updated RHEL3U2 version.

I feel your pain :-) I'm sorry bugzilla did not provide the
information you needed. FWIW bugzilla is not a very adept tool at
handling the situation you stumbled on, which was any executable that
linked with both SASL and LDAP would have problems. It happened to be
first noticed in sendmail, which was the package it was filed against. 

Bugzilla really dosen't have a way of saying "this bug exists in N
packages", rather someone has to manually duplicate the bug for every
package so that if you do a search against the package you find it. In
truth this type of manual bug duplication does not generally happen
:-( And its never too clear when the advantage of bug duplication out
weighs the downside. Perhaps in this instance duplicating the bug
would have been the right answer.

What probably would have worked is to have done a bugzilla query
searching for the text "postfix" anywhere in the bug report. That
would have worked in this case, but there is no guarantee this works
in general and it may generate more query results than you might care
to deal with.

I'm not a fan of duplicated work either and I'm sorry your query did
not produce the information you needed. I hope the explanation helps.

The duplicated bug is listed in comment #5

Oh, I forgot to mention to your building your own 2.0.18 for RHEL3,
there are a few facts you'll want to keep in mind.

FC 2 will have a postfix 2.0.18 shortly.

The rpm built for RHEL3 and for FC are NOT the same!!!!

Why? In part exactly because of the problem you encountered between
the SASL and LDAP libraries. The LDAP in RHEL continues to link
against V1 of SASL and from my understanding LDAP in RHEL3 will always
link against V1 of SASL. Therefore postfix was forked/branched for
RHEL3 to get around this problem. Fedora Core does not have this
problem. Also postfix in FC is getting more "enhancements" such as
IPV6 support, etc. You'll want to be very careful if you're "rolling
your own" so you don't trip up on these things.

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.