Red Hat Bugzilla – Bug 72122
en_GB.UTF-8 and en_US.UTF-8 locale lock up everything
Last modified: 2016-11-24 07:25:56 EST
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
# export LANG="en_GB.UTF-8"
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):
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?
> 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...
With the proposed work-around (de_DE.UTF-8 works!), I see this:
$ export LOCPATH=/usr/lib/locale
$ export LANG="en_GB.UTF-8"
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.