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.
Can you ldd /usr/sbin/httpd on both boxes? rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc
Created attachment 103932 [details] System with expected behaviour
Created attachment 103933 [details] System with incorrect behaviour
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?
I think rpm -Uvh --replacepkgs glibc-2.3.2-95.27.i686.rpm ought be enough.
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?
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.
Nope, this problem was in fact a manual install of RPM. Thanks for your help.