From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809 Description of problem: # xterm -e su - # cat /etc/sysconfig/i18n LANG="de_DE.UTF-8" SUPPORTED="en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en:de_DE.UTF-8:de_DE:de" SYSFONT="LatArCyrHeb-16" # export LANG="en_GB.UTF-8" # up2date At this point, CPU usage rises near 100%, stays there, and up2date does not start. Upon pressing CTRL+C, I can break free from this, but "root" can no longer access the filesystem. Simple operations like "ls" or "ll /var/lib/rpm" hang with 100% and must be interrupted with CTRL+C. Exiting xterm and opening a new one is a work-around. The same with ordinary users instead of "root". It then does not even display the consolehelper root password prompt dialog. Version-Release number of selected component (if applicable): 2.9.46-1 How reproducible: Always Additional info: No such problem with the current default de_DE.UTF-8 locale here. Only when I override the LANG environment variable to either en_GB.UTF-8 or en_US.UTF-8.
whats using all the cpu? up2date or something else (console helper?) Could be a glibc issue. Do other apps work with this locale set this way? Does up2date work with other locales?
> whats using all the cpu? up2date > Do other apps work with this locale set this way? D'oh! No. :-O For instance, "export LANG="en_GB.UTF-8" ; pine" hangs similarly. "ls" hangs, "logout" hangs, everything hangs. *Sorry*, I've been test-driving the German default locale with (null) primarily. Component change to "glibc". > Does up2date work with other locales? In addition to "Additional comment" of the bug report: C : YES en_GB.UTF-8 : NO en_GB : YES en : YES => Using the fallback 'C' locale. en_US.UTF-8 : NO en_US : YES de_DE.UTF-8 : YES de_DE : YES de : YES => Using the fallback 'C' locale.
Changed summary from [up2date] "hangs and locks fs access with en_GB.UTF-8 locale" to [glibc] "en_GB.UTF-8 and en_US.UTF-8 locale lock up everything". glibc and glibc-common packages verify fine. kernels tried: 2.4.18-11.i686 from (null) and 2.4.18-12.athlon from Raw Hide. Actually, when I change the default locale in /etc/sysconfig/i18n to en_GB.UTF-8 (British English has been my default locale so far with Valhalla and older), I cannot even log in anymore (have had to rescue the system). de_DE.UTF-8 seems to work flawlessly (but I don't like that German locale). I can't believe this. If I had installed (null) with en_GB.UTF-8 as default locale as with Limbo and Limbo beta2, would that have worked?
Are you using glibc-2.2.90-24? If so, what happens if you try a different glibc?
This is a known bug http://sources.redhat.com/ml/libc-hacker/2002-08/msg00118.html I'll build a fixed glibc today. As workaround, you can export LOCPATH=/usr/lib/locale and it will work...
Yes, glibc-2.2.90-24. With the proposed work-around (de_DE.UTF-8 works!), I see this: $ export LOCPATH=/usr/lib/locale $ export LANG="en_GB.UTF-8" $ up2date still hangs, CPU usage around 94% now for "/usr/sbin/userhelper -w up2date". Other programs work with this work-around, though.
glibc-2.2.90-26 from (null) 7.3.95-0.20020827 updates fixes this for me.