Hide Forgot
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:
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.
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 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
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: /root/.bashrc /root/.bash_profile /etc/profile /etc/bashrc
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 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
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.