screen error "no more PTYs"

darcon3k · 03-08-2005, 08:44 PM

I'm trying to run screen (version 4.0.2-i486-1) on my slackware box, it used to work fine before but now if I launch it as a user (works fine as root) I get these messages

no more PTYs
Sorry, could not find a PTY
[screen is terminating]

Matir · 03-08-2005, 08:58 PM

Apparently it's looking to allocate ptys. Most likely it's a question of permissions on the /dev/pty* devices. Most likely, they should be 666, I believe.

darcon3k · 03-08-2005, 09:38 PM

Thx for the help Matir, I just checked /dev and theres 257 entries for pty* is this normal? How could I have run out? lol
here's an excerpt of "ls -l /dev/pty*"

Code:

lrwxrwxrwx  1 root root 6 2005-03-08 10:17 /dev/ptya0 -> pty/m0
lrwxrwxrwx  1 root root 6 2005-03-08 10:17 /dev/ptya1 -> pty/m1
lrwxrwxrwx  1 root root 6 2005-03-08 10:17 /dev/ptya2 -> pty/m2
lrwxrwxrwx  1 root root 6 2005-03-08 10:17 /dev/ptya3 -> pty/m3
lrwxrwxrwx  1 root root 6 2005-03-08 10:17 /dev/ptya4 -> pty/m4

all of them have permission 777 so I don't think its a permissions issue, but at then end of the list there's a space and then this

Code:

/dev/pty:
total 0
crw-rw----  1 root root 2, 175 2005-03-08 10:17 m
crw-rw----  1 root root 2, 160 2005-03-08 10:17 m0
crw-rw----  1 root root 2, 161 2005-03-08 10:17 m1
crw-rw----  1 root root 2, 162 2005-03-08 10:17 m2

theres a total of 22 entries like those above with permission 660, but I'm not sure why entries named m, m0,m1,etc... are showing up when I typed pty* ?

darcon3k · 03-10-2005, 04:36 PM

Here's part of my /etc/udev/rules.d/udev.rules

Code:

# pty devices
KERNEL="ptmx",                  NAME="%k", GROUP="tty", MODE="0666"
KERNEL="pty[p-za-e][0-9a-f]*",  NAME="pty/m%n", SYMLINK="%k", GROUP="tty"
KERNEL="tty[p-za-e][0-9a-f]*",  NAME="pty/s%n", SYMLINK="%k", GROUP="tty"

So if I understand this right, all the pty devices should be set to 0666 by udev, but when I "ls -l /dev" it shows that they're all lrwxrwxrwx which is 777?

Also I tried adding myself to the tty group but that didn't help

darcon3k · 03-13-2005, 04:09 PM

finally found the solution, just had to

Code:

chmod 666 /dev/ptmx

hopefully this helps someone else

Edit: next problem I had was after starting screen the only command that worked was cd, every other command resulted in "write error: Bad file descriptor"

the solution was

Code:

chmod 666 /dev/null

serg.kr · 06-16-2008, 09:33 PM

Had a similar problem and found this on google. Unfortunately, changing the permissions did not help in my case. I was able to get screen working after running this command:

Code:

mount -t devpts /dev/ptmx /dev/pts

I'm not entirely sure how or why this worked for me. I surmised this solution after reading this page:

http://www.linuxfromscratch.org/pipe...ay/017234.html

Can anyone explain why this works?

Genotix · 06-23-2008, 06:27 AM

Running SCO 5 at work I discovered a limitation to the screen command.
Only 99 PTY's could be used; having over 250 users, this was an issue.

Note that this issue will probably also occur using BSD and other Unix variants

The reason I wanted this much screens is for a session reliability construction.
(Out remote locations had some problem with internet and the local power supplier)

I kept getting:

No more PTYs
followed by
Sorry, could not find a PTY.

Having browsed through the code I've found a strange piece of code for trying different pty's. The code can be found in the original pty.c file.

Below the diff file(s) to limit to number of PTY's through a setting in in the config.h

pty.c

Code:

< static char PtyProto[] = "/dev/ptypXY";
< static char TtyProto[] = "/dev/ttypXY";
---
> static char PtyProto[] = "/dev/ptyp";
> static char TtyProto[] = "/dev/ttyp";
341c356
<   register int f;
---
>   register int f, x;
342a358
>   // This style is used for our SCO unix environment
344,352c360,361
<   strcpy(PtyName, PtyProto);
344,352c360,361
<   strcpy(PtyName, PtyProto);
<   strcpy(TtyName, TtyProto);
<   for (p = PtyName; *p != 'X'; p++)
<     ;
<   for (q = TtyName; *q != 'X'; q++)
<     ;
<   for (l = PTYRANGE0; (*p = *l) != '\0'; l++)
<     {
<       for (d = PTYRANGE1; (p[1] = *d) != '\0'; d++)
---
> 
>    for (x = 1; x <= PTYMAX; x++)
354,369c363
<         debug1("OpenPTY tries '%s'\n", PtyName);
<         if ((f = open(PtyName, O_RDWR | O_NOCTTY)) == -1)
<           continue;
<         q[0] = *l;
<         q[1] = *d;
<         if (eff_uid && access(TtyName, R_OK | W_OK))
<           {
<             close(f);
<             continue;
<           }
< #if defined(sun) && defined(TIOCGPGRP) && !defined(SUNOS3)
<         /* Hack to ensure that the slave side of the pty is
<          * unused. May not work in anything other than SunOS4.1
<          */
<           {
<             int pgrp;
---
>                 debug1("OpenPTY tries '%s'\n", PtyName);
371,378c365,377
<             /* tcgetpgrp does not work (uses TIOCGETPGRP)! */
<             if (ioctl(f, TIOCGPGRP, (char *)&pgrp) != -1 || errno != EIO)
<               {
<                 close(f);
<                 continue;
<               }
<           }
< #endif
---
>                 sprintf(PtyName, "%s%d", PtyProto, x);
>                 sprintf(TtyName, "%s%d", TtyProto, x);
>                 
>                 if ((f = open(PtyName, O_RDWR | O_NOCTTY)) == -1)
>                   continue;
>                 Msg(0, "Got PTY '%s'\n", PtyName);
> 
>                 if (eff_uid && access(TtyName, R_OK | W_OK))
>            {
>                     close(f);
>                     continue;
>            }
> 
383,384d381
<     }
<   return -1;

In order to compile correctly I needed to change the os.h file too:
os.h

Code:

131c131
< # define ftruncate(fd, s) chsize(fd, s)
---
> //# define ftruncate(fd, s) chsize(fd, s)

After running configure I also needed to add the PTYMAX value to my generated config file
and I modified the MAXWIN value:

config.h

Code:

39c39
< # define MAXWIN 1800
---
> # define MAXWIN 40
664c664
< 
---
> #define PTYMAX 1800

clustermagnet · 11-26-2008, 09:05 AM

Quote:

Originally Posted by serg.kr

Had a similar problem and found this on google. Unfortunately, changing the permissions did not help in my case. I was able to get screen working after running this command:

Code:

mount -t devpts /dev/ptmx /dev/pts

I'm not entirely sure how or why this worked for me. I surmised this solution after reading this page:

http://www.linuxfromscratch.org/pipe...ay/017234.html

Can anyone explain why this works?

Guys, could someone explain? This actually only is the fix for non-root users. Root never had the issue in the first place.

Thanks!

Genotix · 11-27-2008, 02:34 AM

Quote:

Originally Posted by clustermagnet

Guys, could someone explain? This actually only is the fix for non-root users. Root never had the issue in the first place.

Thanks!

Seems to that this fix works when screen expects to
get it's pty's from another location.
By mounting the real location to the 'expected' location screen can appearantly retrieve it's pty's successfully.

Bamm · 01-28-2010, 11:55 AM

When you google "sorry could not find pty" this is the first site that pops up. As I got this error in terminal on my Mac I thought I would post my simple solution, add sudo in front of your command and your good to go. Hope this helps someone...

moggie · 04-19-2011, 04:30 PM

I run Debian (Lenny) and was having the same PTY issue. The solution in my situation was to use MAKEDEV to create a new PTY in /dev as root and thereby facilitate the creation of a new session by a non-root user:

Code:

cd /dev
MAKEDEV pty

Keep in mind you will only create one pty device each time you "MAKEDEV pty", so this is likely not a solution if the number of non-root sessions active at any one time cannot be known ahead of time.