First a lesson on ptys. There are two types of pty's as there are two major
flavors of Unix, BSD and SYSV.
Older versions of Linux used the BSD style try&fail /dev/pty* grabbing method
(aka, a "pty").
Newer versions of Linux use the SYSV ptmux method of opening /dev/ptmx,
usually by using the openpts() call in libutil (aka, a "pts" or "SYSV pty").
This is called a Unix98 style PTY, thus the CONFIG_UNIX98_PTY kernel option.
On Wednesday 04 December 2002 06:25, Mike Manchester wrote:
> I'm trying to run screen on a Redhat 7.3 system and each time I try:
> screen vi somefile
> I receive the message on the terminal that says.
> no more PTY's
> Sorry could not find a PTY
On Red Hat Linux 7.x, the default limit on ptys is set to 2048 for i686
and athlon kernels. Standard i386 and similar kernels default to 256 ptys.
The config directive CONFIG_UNIX98_PTY_COUNT defaults to 256,
but can be set as high as 2048. For 2048 ptys to be supported, the value
of UNIX98_PTY_MAJOR_COUNT needs to be set to 8 in include/linux/major.h
I'll bet you're NOT hitting this limit.
> when I look in /dev I can see 275 PTY's.
Those are merely the static character devices for userspace processes to use
to talk to the major/minor of the pty driver in your kernel. As these files
are NOT automagically generated by your kernel, but typically by hand or via
use of the /dev/MAKEDEV shell script, merely enumerating them tells you
nothing about the current system capacity.
Again, those files are BSD style PTY devices. Only older applications that are
not SYSV /dev/ptmx aware use those files.
I'm pretty sure Redhat 6 and later use the devpts filesystem, which you can
use to truely gauge how many PTYs are in use:
# ls /dev/pts
If not, you can always mount that filesystem yourself manually:
# mkdir /dev/pts
# mount -t devpts devpts /dev/pts
Also, you can mount a full "devfs" filesystem somewhere else:
# mkdir /devfs
# mount -t devfs devfs /devfs
# ls /devfs/pty/
This will give you a more realistic enumeration of all of the pty devices
available on your running kernel.
If you want to see which old-style /dev/pty* are in use, you can either look
at the permissions on the device files (ie, not mode 666 owned by root/tty),
or use lsof with either pty's or pts's:
# lsof +d /dev | grep pt
> How can I get screen to work? Do I need to configure something to use
> more than on PTY? I can get 1 pty if I ssh in but screen apparently
> won't start any more for what ever reason.
Make sure your /dev/pty* files have the correct permissions. By default, they
should be something like:
# chmod 666 /dev/pty*
The ownership on Debian is "root" with group ownership of "tty", I'm unsure of
the default for Redhat 7.x off the top of my head.
Also, try stracing screen to see where it is failing:
$ strace -o /tmp/screen.trace screen vi /tmp/foo
What I'm looking for is a failed openpts() or open() call.
Using google, someone on a mailing list suggested that "screen -a" might
somehow fix it. I don't see how, but it's worth a try.
> Should "screen vi somefile" work when you ssh into a host if the host
> has screen installed (well at least rpm -qa shows the screen package).
Yes. That should work.
-- - Ian C. Blenke <icblenke@nks.net>(This message bound by the following: http://www.nks.net/email_disclaimer.html)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:33:16 EDT