Bug 132766 - Strange threading behaviour with U3
Strange threading behaviour with U3
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-09-16 15:37 EDT by Ken Snider
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: 2004-09-17 09:47:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
System with expected behaviour (1.31 KB, text/plain)
2004-09-16 16:23 EDT, Ken Snider
no flags Details
System with incorrect behaviour (1.30 KB, text/plain)
2004-09-16 16:23 EDT, Ken Snider
no flags Details

  None (edit)
Description Ken Snider 2004-09-16 15:37:07 EDT
We have two systems running the worker-mpm-enabled version of Apache
(Using threads). Both were recently upgraded to U3, both have:


Apache configurations are exactly identical, with 100 worker threads

(Note, this problem affects *all* threaded applications on this box,
not just apache.)

However, one system reacts as expected in a 'ps auxf', and the other
very, very differently:

Box1 (normal behaviour):
root     29366  0.0  1.2 15336 6504 ?        S    Sep09   0:20
apache    1940  0.0  0.3 2068120 1724 ?      S    Sep10   7:06  \_
apache   11652  0.0  1.8 2458528 9620 ?      S    04:02   0:06  \_

Box2 (new behaviour):
root     31058  0.0  0.0 11852  480 ?        S    Sep13   0:14
apache   23823  0.0  0.7 506280 3940 ?       S    Sep14   0:00  \_
apache   23824  0.0  0.7 506280 3940 ?       S    Sep14   0:01      \_
apache   23825  0.0  0.7 506280 3940 ?       S    Sep14   0:00       
  \_ /usr/sbin/httpd.worker
apache   23826  0.0  0.7 506280 3940 ?       S    Sep14   0:00       
  \_ /usr/sbin/httpd.worker
apache   24062  0.0  0.7 506280 3940 ?       S    Sep14   0:01       
  \_ /usr/sbin/httpd.worker
apache   24100  0.0  0.7 506280 3940 ?       S    Sep14   0:01       
  \_ /usr/sbin/httpd.worker

As you can see, Box1 is reacting in proper NPTL fashion, and getpid()
is returning a single PID for all threads on the server. However, Box2
is behaving in a 'pthreads-style' form, with a different process tree
(has a manager thread), and each thread has it's own PID.

This is causing signifigant confusion to our module, which relies on
said PID. LD_ASSUME_KERNEL is set on neither box, nor any other
differing environment variables (or sysctl/proc/etc). I've verified
RPM releases on both servers, and for all I can tell, they are

We've now seen this behaviour on several other systems as well. The
only difference I can see is the upgrade path - a few of these boxes
were upgraded U1-U3, however this does *not* appear to be consistent.
Comment 1 Jakub Jelinek 2004-09-16 15:55:49 EDT
Can you ldd /usr/sbin/httpd on both boxes?
rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc
Comment 2 Ken Snider 2004-09-16 16:23:16 EDT
Created attachment 103932 [details]
System with expected behaviour
Comment 3 Ken Snider 2004-09-16 16:23:45 EDT
Created attachment 103933 [details]
System with incorrect behaviour
Comment 4 Ken Snider 2004-09-16 16:25:18 EDT
checking glibc, one is running the i386 build, the other, i686. I'd be
happy to harmonize them, but I'm not sure what the best procedure is
to overwrite one with the other (because they appear as separate
packages to RPM, and as such, conflict).

Is it safe to perform a --force of the i686 build? Should I -e
--justdb the i386 build and reinstall, or?
Comment 5 Jakub Jelinek 2004-09-16 16:29:49 EDT
I think rpm -Uvh --replacepkgs glibc-2.3.2-95.27.i686.rpm ought be
Comment 6 Ken Snider 2004-09-16 16:32:37 EDT
It wasn't, so I just used -Uvh --force. Worked well enough.

The problem went away as well. Which leaves only one question, is the
behaviour between the i386 and i686 versions *supposed* to differ in
this way?
Comment 7 Jakub Jelinek 2004-09-16 16:43:50 EDT
NPTL requires some atomic instructions which the i386 architecture
doesn't have, so NPTL is only included in i686.rpm glibc on IA-32.

Now, the question is why you had .i386.rpm glibc installed.
Certainly up2date should choose the right architecture (as well
as other upgrade tools).

If it was installed by rpm and not an updating program, then I think
this bug can be closed.  If installation of i386.rpm was because
of fault in up2date, we need to know details.
Comment 8 Ken Snider 2004-09-17 09:47:05 EDT
Nope, this problem was in fact a manual install of RPM. Thanks for
your help.

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