Bug 132766

Summary: Strange threading behaviour with U3
Product: Red Hat Enterprise Linux 3 Reporter: Ken Snider <ksnider>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-17 09:47:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
System with expected behaviour
none
System with incorrect behaviour none

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:

glibc-common-2.3.2-95.27
glibc-2.3.2-95.27
kernel-smp-2.4.21-20.EL

Apache configurations are exactly identical, with 100 worker threads
running. 

(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
/usr/sbin/httpd.worker
apache    1940  0.0  0.3 2068120 1724 ?      S    Sep10   7:06  \_
/usr/sbin/httpd.worker
apache   11652  0.0  1.8 2458528 9620 ?      S    04:02   0:06  \_
/usr/sbin/httpd.worker

Box2 (new behaviour):
root     31058  0.0  0.0 11852  480 ?        S    Sep13   0:14
/usr/sbin/httpd.worker
apache   23823  0.0  0.7 506280 3940 ?       S    Sep14   0:00  \_
/usr/sbin/httpd.worker
apache   23824  0.0  0.7 506280 3940 ?       S    Sep14   0:01      \_
/usr/sbin/httpd.worker
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
*identical*.

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
enough.
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.