Bug 212966 - unicode_start prevents su'ing to root in a console
Summary: unicode_start prevents su'ing to root in a console
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils   
(Show other bugs)
Version: rawhide
Hardware: i686 Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-30 12:40 UTC by david.hagood
Modified: 2008-03-13 08:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-13 08:37:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
i18n config per request (47 bytes, application/octet-stream)
2006-11-01 01:20 UTC, david.hagood
no flags Details

Description david.hagood 2006-10-30 12:40:52 UTC
Description of problem:
/bin/unicode_start takes a LONG time to finish, if ever, if launched from a
console (instead of from an Xterm), so when I log in as my normal user account
and then su to do some work from a console, it can take anywhere from a minute
to forever for the su to complete - meanwhile unicode_start is messing with the
monitor's scan rates and making the monitor look like somebody dumped a handful
of graphite into the high voltage section.

I've verified the culprit by logging in from another computer and ps'ing and
running top while this happens.

Version-Release number of selected component (if applicable):
FC6-T1 through FC6, kbd-1.12-18

How reproducible:
every time

Steps to Reproduce:
1) Log in as normal user from a text console - NOT an Xterm.
2) su - root
3) input root's password

Actual results:
SU takes a LONG time to return - if ever. Monitor scan rates are constantly
being changed such that the monitor is glitching badly.

Expected results:
su should present a login shell within a couple of seconds after the password is
correctly given.

Additional info:

Comment 1 Miloslav Trmač 2006-10-31 15:47:19 UTC
Please attach your /etc/sysconfig/i18n.

Also, as a non-root user, please log in to the console, and run the following
(su -c 'strace -o log -ff -T bash -c /etc/profile.d/lang.sh')
This should produce a few log files; pack them:
(tar czf logs.tar.gz log*)
and attach the created file logs.tar.gz to this bug report.

Comment 2 david.hagood 2006-11-01 01:20:30 UTC
Created attachment 139929 [details]
i18n config per request

Comment 3 david.hagood 2006-11-01 01:43:12 UTC
I attempted to run the su command as requested.

SU prompted me for the root password as expected.

It then stopped responding - as expected (hence the bug report).

I left the room for 5 minutes. When I came back, nothing had happened, so I
attempted to switch to another virtual console to see what was going on.

And then the flickering (as described above) started.

I let it run that way for thirty seconds, switching from the new VC to the VC
upon which the su command was running. While I could switch consoles, the
flickering continued.

Finally, I hit CTRL-C on the su session - and the flickering stopped. However,
the session did not terminate.

I then switched to a new VC and tried to log in as root - and the system froze
before asking me for my password.

I then tried to switch to my running X session, so that I could try to kill
things from there - and the system froze with a blank screen. By "froze", I mean
that the system was unresponsive to key presses - even to the point that
pressing CAPSLOCK would not toggle the caps lock LED.

I then went to another room to get my PDA to try to SSH in. In the time it took
me to get the PDA, X had come up.

Also, back on the VC, the SU session had terminated.

However, NO log files were created - hence why I didn't attach them.

It is as if the problem lies within SU, and as such the strace command never got

For reference, coreutils (owner of SU) is coreutils-5.97-13

Comment 4 Miloslav Trmač 2006-11-01 01:51:40 UTC
Thanks, that indeed seems to point to coreutils, although I can't think of
a plausible explanation.  Maybe an unusual PAM module?

Comment 5 david.hagood 2006-11-01 02:05:36 UTC
I cannot think of anything unusual in PAM.

Now, the system *is* running NIS for user authentication - but I am at a loss as to

a) how that would affect ROOT
b) how that would be different between SU'in in an Xterm and SU'ing in a VC.

Comment 6 Tim Waugh 2006-11-10 12:52:50 UTC
If you run 'su' without the '-', does it also happen then?

I suspect one of these files has something iffy in it:


Comment 7 david.hagood 2006-11-10 23:30:51 UTC
The same thing happens for "su" as "su -".

Comment 8 Tim Waugh 2006-12-07 13:06:05 UTC
What does 'rpm -V setup' say, and what's in /root/.bashrc and /root/.bash_profile?

Comment 9 david.hagood 2006-12-07 23:24:07 UTC
rpm -V setup
S.5....T c /etc/aliases
S.5....T c /etc/printcap

 cat /root/.bashrc 
# .bashrc

# User specific aliases and functions

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
[root@surfer tmp]# cat /root/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc

# User specific environment and startup programs


export PATH

Comment 10 Ondrej Vasik 2008-03-12 13:54:52 UTC
Sorry - I got maintainance of coreutils in 10/2007 and was not able to reproduce
the problem on my machine. As FC-6 is EOL - this bugzilla should get closed or
moved to rawhide or higher Fedora number. I prefer rawhide and changing to
needinfo. My question is following:
Does the error still occur with latest Fedora(F8) ?

Comment 11 david.hagood 2008-03-13 01:02:15 UTC
I've lost my Fedora workstation, and cannot reproduce this on my Fedora server.

Close it out WFM I guess

Comment 12 Ondrej Vasik 2008-03-13 08:37:52 UTC
Ok, closing WFM, feel free to reopen when you get this problem on later (not
EOL) Fedora workstation.

Note You need to log in before you can comment on or make changes to this bug.