Red Hat Bugzilla – Full Text Bug Listing
|Summary:||sshd cannot open pty for shell session|
|Product:||[Fedora] Fedora||Reporter:||G.Wolfe Woodbury <redwolfe>|
|Component:||openssh||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 14:04:27 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description G.Wolfe Woodbury 2004-07-15 00:31:43 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: "ssh -X email@example.com" hangs because the far end cannot open/allocate a pty for the shell. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.ssh [-X] firstname.lastname@example.org 2. 3. Actual Results: session hangs with error in /var/log/secure Jul 15 00:23:27 tembo sshd: pam_succeed_if: requirement "uid < 100" not met by user "ggw" Jul 15 00:23:27 tembo sshd: Accepted password for ggw from ::ffff:10.11.12.3 port 1215 ssh2 Jul 15 00:24:48 tembo sshd: error: openpty: No such file or directory Jul 15 00:24:49 tembo sshd: error: session_pty_req: session 0 alloc failed Expected Results: normal shell Additional info:
Comment 1 G.Wolfe Woodbury 2004-07-15 19:12:31 EDT
rawhide update of 2004-07-15 (kernel -1.488) seems to have fixed the problem.
Comment 2 Barry K. Nathan 2004-07-26 09:10:40 EDT
I'm still seeing this with kernel -1.494. However, it's actually a more general problem -- after a few hours of uptime or so, *all* processes (NOT just sshd!) are unable to obtain pty's...
Comment 3 Geoff Reedy 2004-07-28 21:53:26 EDT
I'm getting this as well (I'm also running 2.6.7-1.494). I'm surprised that the problem is not more widespread (i.e. I haven't seen anything about it in the mailing lists). I think its a kernel bug, I don't remember the last time this was working right so its hard to say when the problem was introduced. I wrote a little test program and strace'd sshd and the attempt to open /dev/ptmx is returning -EIO. The best I can tell from the kernel source the code that tries to get a number for the pty to use is either getting a pty id that is bigger than the max or the function that gets the id (idr_get_new) is returning an error. Since the biggest pty number I got to was maybe 12 I think it is probably the latter. I know there has been a lot of changes in the pty allocation code recently, is there perhaps a missing free/unlock/release or something of that nature?
Comment 4 Barry K. Nathan 2004-07-28 22:43:37 EDT
A patch just went into 2.6.8-rc2-mm1 for a pty leak or something like that, FWIW...
Comment 5 Barry K. Nathan 2004-07-28 22:50:37 EDT
FWIW, I've seen this problem on 2.6.x kernels but not 2.4.x kernels (and I don't think I saw it on 2.5.x either). That's my best recollection as to when this showed up.
Comment 6 Barry K. Nathan 2004-07-29 17:23:37 EDT
This bug at least depends on fixing bug 128154 first -- if it's not a dupe of bug 128154, in fact.
Comment 7 Geoff Reedy 2004-07-29 18:25:54 EDT
That patch is in 2.6.8-rc2-bk6 which if the changelog is true is what linux-2.6.7-1.499 rpm is based on. Hopefully that update will fix it. In any case I'm pretty sure its a dupe since when I have the problem with ssh I also have the problem with opening up new terminal windows.
Comment 8 Barry K. Nathan 2004-07-29 19:54:32 EDT
Actually, no, the patch didn't make it into mainline until 2.6.8-rc2-bk8, so it's not in 2.6.7-1.499... Right now I'm compiling RPMS of 2.6.7-1.499 + the patch.
Comment 9 Geoff Reedy 2004-07-29 20:56:38 EDT
Oops, misread the 6 as an 8. I've already been running 1.494 with the patch and the thing just happened again. On the other bugs people say it happens after the system has been running for a certain amount of time (usually they reckon after a day or so). Mine did it after just 11 hours. And I did less pty allocation then ever before since most of those 11 hours I was at work. I only got 3 terminals open pts/0 through 2.
Comment 10 Barry K. Nathan 2004-07-30 00:23:57 EDT
Sometimes I've seen it happen after only 2 hours, although it does seem to happen more often as the system uptime increases. Somewhere in bug 128154 there's a procedure for reproducing this bug. Hopefully I'll get a chance to set up a test system and try the reproduction procedure on that. It might be interesting to try a mainline kernel, in case this is being caused by one of Red Hat's patches (not likely IMO, but who knows).
Comment 11 Geoff Reedy 2004-08-01 15:04:42 EDT
Okay, I've thrown some printks around the tty code and the source of the EIO is in the fast_track of init_dev in tty_io.c. Since we are trying to get a new pty, not open an existing one, something must be causing the fast track to be taken in error. The code consults the devpts driver to see if the id returned from the idr functions corresponds to an existing pty. As far as I can tell it means that either the idr functions are returning an in-use id, devpts is messed up, or memory is not being initialized properly. I'm throwing in some more printks to see if I can find anything else out.
Comment 12 Bill Nottingham 2004-08-05 14:27:39 EDT
*** This bug has been marked as a duplicate of 128154 ***
Comment 13 Red Hat Bugzilla 2006-02-21 14:04:27 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.