Bug 161327 - Select on master pty not returning when slave closed
Select on master pty not returning when slave closed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-22 10:08 EDT by Enrique Perez-Terron
Modified: 2015-01-04 17:20 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 17:38:29 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 Enrique Perez-Terron 2005-06-22 10:08:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i586; en) Opera 8.0

Description of problem:
sshd waits in select (/proc/*/wchan is _stext) after the child process is 
terminated.



Version-Release number of selected component (if applicable):
kernel-2.6.11-1.1369_FC4

How reproducible:
Sometimes

Steps to Reproduce:
1. From another (client) computer, ssh server
2. exit bash
3.
  

Actual Results:  In terminal window on client computer, the ssh command does not terminate:
[serveruser@serverPC serverdir] $ exit
Logout
(cursor bliknks here)

Expected Results:  In terminal window on client computer, the ssh command terminates and the client 
computer shell prompts for the nest command:
[serveruser@serverPC serverdir] $ exit
Logout
Connection to server closed.
[localuser@clientPC localdir] $ (cursor blinks here)

Additional info:

On the server, ps shows
  user 8383 ... sshd: user@notty
and there is no child process. Observe that ordinarily the command line shows 
"sshd user@pts/1" or similar.

strace -p 8383 shows
  select(9, [3 5 8], [], NULL, NULL <unfinished ...>
lsof -p 8383 shows
  sshd 8383 user 3u  IPv6     977353    TCP serverPC:ssh->clientPC:49997 
(ESTABLISHED)
  sshd 8383 user 4u  unix 0xca6ee2a0 977411 socket
  sshd 8383 user 5r  FIFO        0,5 977419 pipe
  sshd 8383 user 6w  FIFO        0,5 977419 pipe
  sshd 8383 user 8u   CHR        5,2    680 /dev/ptmx

Observe that before terminating bash, there are file descriptors 7,8,&9
all pointing to the same file as 8 above, CHR 5,2 /dev/ptmx.

"ps -ef | grep pts/" shows no other ptys than pts/1, used by a second ssh login; 
however, "cat /proc/sys/pty/nr" shows 4.
Comment 1 Dave Jones 2005-07-15 17:55:30 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 2 Dave Jones 2005-09-30 02:42:22 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 3 Enrique Perez-Terron 2005-10-02 01:06:54 EDT
since the error was intermittent, it was difficult to judge it
when it did not happen. But the error has not returned since
I upgraded to the 2.6.12-1.1398_FC4 kernel, so I now think it
must have been fixed.

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