Bug 37615 - Doing 'su' as root hangs
Doing 'su' as root hangs
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: sh-utils (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
: 40348 42555 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-25 09:46 EDT by Anders Peter Fugmann
Modified: 2007-04-18 12:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-25 09:46:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anders Peter Fugmann 2001-04-25 09:46:32 EDT
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 09:55:14 EDT
Can't reproduce this. Make sure you aren't using broken ~/.termcap and/or 
~/.terminfo files.

Comment 2 Need Real Name 2001-05-04 06:15:50 EDT
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 06:20:13 EDT
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 16:20:46 EDT
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 08:28:17 EDT
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 09:41:31 EDT
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 08:06:31 EDT
Folks, 

I've entered a similar bug, bugID 40348
Comment 8 Bernhard Rosenkraenzer 2001-05-14 06:41:31 EDT
*** Bug 40348 has been marked as a duplicate of this bug. ***
Comment 9 Bernhard Rosenkraenzer 2001-05-28 08:15:33 EDT
*** 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.