"Plus de PTY" lors de la tentative de démarrage de l'écran

Lorsque j'essaie de démarrer «écran» ou «byobu», j'obtiens le message d'erreur suivant:

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

Il me semble cependant que j'en ai assez:

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

Quelques informations supplémentaires:

$ 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

Si vous avez besoin de plus d'informations, veuillez commenter. C'est sur un VPS bas de gamme, mais il fonctionnait très bien jusqu'à ce qu'il cesse de fonctionner. Mais tout le reste semble aller bien.

Avoir zéro ptys est inhabituel, car la connexion SSH que vous utilisez a un pty alloué.

Assurez-vous d'avoir devptsmonté:

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

Si ce n'est pas le cas:

# mount devpts /dev/pts -t devpts -o mode=620

J'ai eu un problème similaire, mais mon problème est survenu lorsque j'ai démarré un conteneur LXC dans mon système (et l'arrêter n'a pas aidé). Il s'est avéré que lorsque screen (dans mon système de base) essayait d'ouvrir un nouveau PTY, il en ouvrait un déjà existant et ne pouvait pas changer de propriétaire.

C'était très étrange, mais l'endroit le plus évident était le point de montage / dev / pts, donc je l'ai simplement remonté:

# mount -o remount /dev/pts

et les problèmes ont disparu. Je n'ai "perdu" aucun périphérique PTY de / dev / pts après le remontage, donc cela semble une opération assez sûre.

J'ai eu un problème similaire, mais le problème était des autorisations incorrectes des périphériques / dev / pt *.

Je ne sais pas pourquoi ils ont été définis sur 600, donc seule la racine peut utiliser l'écran, je suis passé à 666 et cela a fonctionné pour les autres utilisateurs.