Bug 132766 - Strange threading behaviour with U3
Summary: Strange threading behaviour with U3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-09-16 19:37 UTC by Ken Snider
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-17 13:47:05 UTC
Target Upstream Version:
Embargoed:


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

Description Ken Snider 2004-09-16 19:37:07 UTC
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 19:55:49 UTC
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 20:23:16 UTC
Created attachment 103932 [details]
System with expected behaviour

Comment 3 Ken Snider 2004-09-16 20:23:45 UTC
Created attachment 103933 [details]
System with incorrect behaviour

Comment 4 Ken Snider 2004-09-16 20:25:18 UTC
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 20:29:49 UTC
I think rpm -Uvh --replacepkgs glibc-2.3.2-95.27.i686.rpm ought be
enough.

Comment 6 Ken Snider 2004-09-16 20:32:37 UTC
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 20:43:50 UTC
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 13:47:05 UTC
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.