Bug 118234 - process /usr/libexec/postfix/pickup pid 24492 killed by signal 11
process /usr/libexec/postfix/pickup pid 24492 killed by signal 11
Status: CLOSED DUPLICATE of bug 111767
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: postfix (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
Depends On:
  Show dependency treegraph
Reported: 2004-03-14 02:29 EST by Graham Leggett
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:01:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backtrace of segfault from xxgdb (2.22 KB, text/plain)
2004-03-14 08:47 EST, Graham Leggett
no flags Details

  None (edit)
Description Graham Leggett 2004-03-14 02:29:44 EST
Description of problem:

When the standard Postfix as released with RHEL3 is configured with
LDAP maps, the following errors are logged:

Mar 14 09:23:05 dungeon postfix/master[22256]: warning: process
/usr/libexec/postfix/pickup pid 24280 killed by signal 11
Mar 14 09:23:05 dungeon postfix/master[22256]: warning:
/usr/libexec/postfix/pickup: bad command startup -- throttling
Mar 14 09:24:05 dungeon postfix/master[22256]: warning: process
/usr/libexec/postfix/pickup pid 24492 killed by signal 11
Mar 14 09:24:05 dungeon postfix/master[22256]: warning:
/usr/libexec/postfix/pickup: bad command startup -- throttling
Mar 14 09:24:05 dungeon postfix/master[22256]: warning: process
/usr/libexec/postfix/nqmgr pid 24493 killed by signal 11

If the package is rebuilt from source, the following error is emitted:

gcc -Wmissing-prototypes -Wformat -DHAS_LDAP -DHAS_PCRE
-I/usr/include/pcre -I/usr/include/sasl -DUSE_SASL_AUTH -DHAS_SSL
-I/usr/kerberos/include  -DINET6 -D__ss_family=ss_family  -O2 -g -pipe
-march=i386 -mcpu=i686 -I. -I../../include -DLINUX2 -o qmgr qmgr.o
qmgr_active.o qmgr_transport.o qmgr_queue.o qmgr_entry.o
qmgr_message.o qmgr_deliver.o qmgr_move.o qmgr_rcpt_list.o qmgr_job.o
qmgr_peer.o qmgr_defer.o qmgr_enable.o qmgr_scan.o qmgr_bounce.o
../../lib/libmaster.a ../../lib/libglobal.a ../../lib/libutil.a
-L/usr/lib -lldap -llber -lpcre -lsasl2 -L/usr/kerberos/lib -lssl
-lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto -lresolv -ldl -lz
-lz -ldb -lnsl -lresolv
/usr/bin/ld: warning: libcom_err.so.3, needed by /usr/lib/libssl.so,
may conflict with libcom_err.so.2 

It seems the libcom_err library is installed twice:

[root@dungeon root]# rpm -q -f /usr/kerberos/lib/libcom_err.so.3
[root@dungeon root]# rpm -q -f /lib/libcom_err.so.2.0

And if the -devel packages for both the packages are present, an
attempt is made to link both libraries.

Removing the e2fsprogs-devel package does not fix the situation :(

The config works fine under Redhat v9 - the same config file breaks
RHEL3 Postfix.

Please mail me privately for a copy of the config file.
Comment 1 Graham Leggett 2004-03-14 05:48:59 EST
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.
Comment 2 Graham Leggett 2004-03-14 06:43:50 EST
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.
Comment 3 Graham Leggett 2004-03-14 08:47:18 EST
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.
Comment 4 Graham Leggett 2004-03-14 10:07:23 EST
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!
Comment 5 John Dennis 2004-03-15 10:37:39 EST
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:


*** This bug has been marked as a duplicate of 111767 ***
Comment 6 John Dennis 2004-03-15 11:04:47 EST
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?
Comment 7 David Lawrence 2004-03-15 12:39:53 EST
Changing product and version.
Comment 8 Graham Leggett 2004-03-15 16:24:06 EST
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 

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.
Comment 9 Graham Leggett 2004-03-15 16:27:34 EST
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.
Comment 10 John Dennis 2004-03-15 17:02:58 EST
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.
Comment 11 John Dennis 2004-03-15 17:06:18 EST
The duplicated bug is listed in comment #5
Comment 12 John Dennis 2004-03-15 17:25:29 EST
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.
Comment 13 Red Hat Bugzilla 2006-02-21 14:01:58 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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