Bug 37615 - Doing 'su' as root hangs
Summary: Doing 'su' as root hangs
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sh-utils
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
URL:
Whiteboard:
: 40348 42555 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-25 13:46 UTC by Anders Peter Fugmann
Modified: 2007-04-18 16:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-04-25 13:46:36 UTC
Embargoed:


Attachments (Terms of Use)

Description Anders Peter Fugmann 2001-04-25 13:46:32 UTC
When issuing the command 'su' as root, 'su' hang in  
"stty rease ?" (which has state T).

Sending a SIGKILL to the stopped 'stty' process, makes su complete.
Btw. the 'stty' process is owned by the new user, and is a child of 
the shell of the new user.

The problem does not occur when doing 'su' as a regular user.

The problem is very easy to reproduce: Do an su as root.Using I'm 
 
I'm using sh-utils-2.0-13. The system is an upgraded 7.1 from a RedHat 7.0.
I have not tested this on a clean RedHat 7.1.

Comment 1 Bernhard Rosenkraenzer 2001-04-25 13:55:14 UTC
Can't reproduce this. Make sure you aren't using broken ~/.termcap and/or 
~/.terminfo files.



Comment 2 Need Real Name 2001-05-04 10:15:50 UTC
I am seeing this exact same problem on several systems after upgrading or 
installing Red Hat 7.1 on them. It does not happen every time, but occasionally 
it will hang in this exact fashion. In my experience, 'sudo' is more prone to 
this problem than plain 'su', but that could be a coincidence.

I did an strace of the stty-proces that is hung, and it is looping endlessly 
trying to do an ioctl on file-descriptor 0 - the ioctl returns -ERESTARTSYS, so 
it is understandable that it keeps looping.

I have seen this on two laptops (fresh installs of 7.1), and on two desktop 
systems with very different hardware, that were upgraded from 7.0.

Let me know if you need any other info to research this.

Henrik


Comment 3 Need Real Name 2001-05-04 10:20:13 UTC
It just happened again, so I repeated the strace. Here is where it's looping:

ioctl(0, SNDCTL_TMR_STOP, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (
To be restarted)
--- SIGTTOU (Stopped (tty output)) ---
--- SIGTTOU (Stopped (tty output)) ---
ioctl(0, SNDCTL_TMR_STOP, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (
To be restarted)
--- SIGTTOU (Stopped (tty output)) ---
--- SIGTTOU (Stopped (tty output)) ---
ioctl(0, SNDCTL_TMR_STOP, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (
To be restarted)
--- SIGTTOU (Stopped (tty output)) ---
--- SIGTTOU (Stopped (tty output)) ---
ioctl(0, SNDCTL_TMR_STOP, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (
To be restarted)
--- SIGTTOU (Stopped (tty output)) ---
--- SIGTTOU (Stopped (tty output)) ---

The command I used was "sudo su -". I have sudo setup to allow me to run all 
commands without a password from this account.


Henrik


Comment 4 Anders Peter Fugmann 2001-05-04 20:20:46 UTC
Problem found:

I found that there is a problem with /etc/bashrc.

It executes the command 'tput kbs',
and tests the output for a zero length string.

Sometimes the string is of non zero length, but is an unprintable character
and thus 'stty' hangs (see details in /etc/bashrc).

I removed the inner 'if then' statement in /etc/bashrc, and all works correctly.


 


Comment 5 Phil Knirsch 2001-05-08 12:28:17 UTC
Hi Henrik!

I've been able to continually reproduce the problem on one of my 7.1
installations.

The problem actually steems from a combined kernel/glibc ioctl
missunderstanding, so updating to the newest kernel and glibc package should
have fixed the problem as well.

Just my $0.02 (and to give some more info ;).

Read ya, Phil

Comment 6 Need Real Name 2001-05-08 13:41:31 UTC
Hi Phil,

"updating to the newest kernel and glibc package should have fixed the problem"

well, 7.1 does not have any updates for neither the kernel nor the glibc 
packages, and a clean 7.1 install shows the problem. So what packages are you 
thinking of - rpms from rawhide ?

I would appreciate it if you could point me in the direction of what patches 
need to be applied to the current 7.1 glibc/kernel rpms.

Thanks,
Henrik

Comment 7 Need Real Name 2001-05-12 12:06:31 UTC
Folks, 

I've entered a similar bug, bugID 40348

Comment 8 Bernhard Rosenkraenzer 2001-05-14 10:41:31 UTC
*** Bug 40348 has been marked as a duplicate of this bug. ***

Comment 9 Bernhard Rosenkraenzer 2001-05-28 12:15:33 UTC
*** Bug 42555 has been marked as a duplicate of this bug. ***


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