12

When I try to start 'screen' or 'byobu', I get the following error message:

$ screen
No more PTYs.
Sorry, could not find a PTY.
[screen is terminating]

I seem to have enough though:

$ ls /dev/pts  
$ cat /proc/sys/kernel/pty/nr
0
$ cat /proc/sys/kernel/pty/max
4096

Some more info:

$ uname -a
Linux cube.mydedi.net 2.6.18-194.8.1.el5.028stab070.5 #1 SMP Fri Sep 17 19:10:36 MSD 2010 x86_64 x86_64 x86_64 GNU/Linux

If you need any more info please comment. This is on a low-end VPS, but it used to work just fine, until it stopped working. Everything else seems to be fine though.

3 Answers 3

11

Having zero ptys is unusual, as the very SSH connection you are using has a pty allocated.

Make sure you have devpts mounted:

$ grep /dev/pts /proc/mounts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0

If it is not:

# mount devpts /dev/pts -t devpts -o mode=620
1
  • You were right. A simple "sudo mount devpts /dev/pts -t devpts" solved my problem. Not sure why is devpts not auto-mounted though...
    – Attila O.
    Commented Jun 27, 2011 at 8:56
2

I had a similar issue, but my problem arised when I started an LXC container within my system (and stopping it didn't help). It turned out that when screen (in my base system) was trying to open a new PTY, it was opening one that was already existing, and couldn't change its ownership.

It was very strange, but the most obvious place was the /dev/pts mountpoint, so I simply remounted it:

# mount -o remount /dev/pts

and the problems went away. I didn't "lose" any PTY devices from /dev/pts after remounting, so it seems a pretty safe operation.

0

I had similar issue, but the problem was wrong permissions of /dev/pt* devices.

Not sure why they were set to 600, so only the root could use screen, I changed to 666 and it worked for other users.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .