Bug 127902 - sshd cannot open pty for shell session
sshd cannot open pty for shell session
Status: CLOSED DUPLICATE of bug 128154
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-15 00:31 EDT by G.Wolfe Woodbury
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:04:27 EST
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 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 user@tembo.private" 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] user@host.domain
2.
3.
    

Actual Results:  session hangs with error in /var/log/secure

Jul 15 00:23:27 tembo sshd[30018]: pam_succeed_if: requirement "uid <
100" not met by user "ggw"
Jul 15 00:23:27 tembo sshd[30018]: Accepted password for ggw from
::ffff:10.11.12.3 port 1215 ssh2
Jul 15 00:24:48 tembo sshd[30018]: error: openpty: No such file or
directory
Jul 15 00:24:49 tembo sshd[30020]: 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.

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