On 01/26/2013 08:46 PM, Mike Edenfield wrote: > At some point recently, one of my systems has begun having problems > allocating pseudo-terminals via the UNIX98 pty scheme. I am using the same > kernel configuration I've had for years, and running the latest ~amd64 > version of all the relevant packages. The problem manifests itself on any > program that attempts to allocate a pseudo-terminal, including portage and > openssh. I first noticed the problem when I could no longer ssh into the > server because it would not allocate a pty. > > I have the latest udev installed, and udev-mount is running on boot. Both > /dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable: > > basement package.use # mount | grep /dev > /dev/root on / type ext3 > (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) > devpts on /dev/pts type devpts > (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime) > udev on /dev type devtmpfs > (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) > > basement package.use # ls -alF /dev/ptmx /dev/pts > crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx > > /dev/pts: > total 0 > drwxr-xr-x. 2 root root 40 Jan 26 13:18 ./ > drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ > > When I trace sshd's attempt to open a new pty, I see it doing this: > > * open /dev/ptmx > * stat /dev/pts > * stat /dev > * try (and fail) to open /dev/ptyp0 > > Since I know that last bit is openssh trying to open an old-style BSD pty, I > can only assume that something is going wrong trying to allocate the pty the > correct way. > > For the time being I've added BSD pty support into my kernel and everything > seems to be working now, but I'm at a loss as to what I did to break things > in the first place.
Do you have any files left in /usr/lib/udev ? If so, try re-emerging the package that owns those files.
