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
Steps to Reproduce:
1) Log in as normal user from a text console - NOT an Xterm.
2) su - root
3) input root's password
SU takes a LONG time to return - if ever. Monitor scan rates are constantly
being changed such that the monitor is glitching badly.
su should present a login shell within a couple of seconds after the password is
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.
Created attachment 139929 [details]
i18n config per request
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
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
Thanks, that indeed seems to point to coreutils, although I can't think of
a plausible explanation. Maybe an unusual PAM module?
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.
If you run 'su' without the '-', does it also happen then?
I suspect one of these files has something iffy in it:
The same thing happens for "su" as "su -".
What does 'rpm -V setup' say, and what's in /root/.bashrc and /root/.bash_profile?
rpm -V setup
S.5....T c /etc/aliases
S.5....T c /etc/printcap
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
[root@surfer tmp]# cat /root/.bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
# User specific environment and startup programs
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) ?
I've lost my Fedora workstation, and cannot reproduce this on my Fedora server.
Close it out WFM I guess
Ok, closing WFM, feel free to reopen when you get this problem on later (not
EOL) Fedora workstation.