This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 212966

Summary: unicode_start prevents su'ing to root in a console
Product: [Fedora] Fedora Reporter: david.hagood
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: meyering, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-13 04:37:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
i18n config per request none

Description david.hagood 2006-10-30 07:40:52 EST
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 10:47:19 EST
Please attach your /etc/sysconfig/i18n.

Also, as a non-root user, please log in to the console, and run the following
command:
(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-10-31 20:20:30 EST
Created attachment 139929 [details]
i18n config per request
Comment 3 david.hagood 2006-10-31 20:43:12 EST
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
executed.

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

Comment 4 Miloslav Trmač 2006-10-31 20:51:40 EST
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-10-31 21:05:36 EST
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 07:52:50 EST
If you run 'su' without the '-', does it also happen then?

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

/root/.bashrc
/root/.bash_profile
/etc/profile
/etc/bashrc
Comment 7 david.hagood 2006-11-10 18:30:51 EST
The same thing happens for "su" as "su -".
Comment 8 Tim Waugh 2006-12-07 08:06:05 EST
What does 'rpm -V setup' say, and what's in /root/.bashrc and /root/.bash_profile?
Comment 9 david.hagood 2006-12-07 18:24:07 EST
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
fi
[root@surfer tmp]# cat /root/.bash_profile 
# .bash_profile

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

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH
unset USERNAME
Comment 10 Ondrej Vasik 2008-03-12 09:54:52 EDT
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-12 21:02:15 EDT
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 04:37:52 EDT
Ok, closing WFM, feel free to reopen when you get this problem on later (not
EOL) Fedora workstation.