¿Por qué obtengo "la pantalla está terminando" sin root?

He instalado la pantalla en Fedora 19. Cuando pruebo el comando como root de forma remota a través de SSH, funciona perfectamente. Por ejemplo, si ingreso screenun nuevo emulador de terminal se inicia y espera los comandos. Puedo desconectarlo, etc. Sin embargo, cuando trato de hacer lo mismo una vez que estoy conectado de forma remota a través de SSH como usuario estándar, el comando termina inmediatamente. El único mensaje que veo es [screen is terminating].

¿Alguien ya ha tenido este problema? ¿Está relacionado con malos permisos?

Actualizar:

$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK)  = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/run/utmp", O_RDONLY)         = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
lstat("/dev/pts/0", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
stat("/var/run/screen", {st_mode=S_IFDIR|0775, st_size=60, ...}) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++

Intenté cambiar los permisos a 777 pero luego cuando ejecuto screen, obtengo:

El directorio '/ var / run / screen' debe tener el modo 775.

Por lo tanto, he revertido mis cambios.

El flip-flop entre "debe tener el modo 777" y "debe tener el modo 775" es causado por strace.

screengeneralmente es un programa setuid o setgid. Obtiene privilegios adicionales cuando se ejecuta, que se utiliza para crear archivos de socket y / o modificar utmp.

Cuando se rastrea un proceso, setuid y setgid están deshabilitados. El proceso de rastreo, controlado por el usuario menos privilegiado, puede hacerse cargo del proceso rastreado, por lo que debe ejecutarse sin sus privilegios adicionales para evitar darle demasiado poder al usuario original.

screen detecta si se está ejecutando con privilegios setuid, privilegios setgid o ninguno de los dos, y ajusta sus expectativas de los permisos del directorio en consecuencia.

Entonces, esto crea una clase de problemas que no se pueden depurar fácilmente strace.

Pero si eres root, ¡hay una solución! Si el proceso de rastreo se ejecuta como root, entonces el proceso rastreado puede obtener privilegios normalmente. Entonces, esto es lo que haces:

1. Abrir 2 nuevas terminales
2. En la primera terminal, inicie sesión en la máquina remota como root
3. En la segunda terminal, inicie sesión en la máquina remota como usuario normal
4. Use pspara obtener el PID del proceso de shell del usuario normal en el segundo terminal
5. En la primera terminal, ejecuta strace -f -p SHELLPID
6. En la segunda terminal, ejecuta la pantalla y mira cómo falla
7. En la primera terminal, ahora tiene el registro de strace que necesita para descubrir qué está realmente mal.

La adición clave al stracecomando es la -fopción, que le dice que rastree los procesos secundarios. Lo necesita para rastrear la pantalla que será un elemento secundario del proceso de shell que especificó -p.

También me gusta usar -ffy especificar un archivo de salida con -o, como en

strace -ff -o /tmp/screentrace -p SHELLPID

que creará un archivo de salida separado para cada proceso secundario. Luego los lees less /tmp/screentrace*y el resultado suele ser más limpio que el que obtienes usando uno solo -f.

ACTUALIZAR

Ahora que he visto la salida de strace, no sé exactamente qué salió mal, pero esta línea es lo más sorprendente en la traza:

chown("/dev/pts/2", 1002, 5)            = -1 EPERM (Operation not permitted)

Unas pocas líneas antes, creó una pty, que fue revelada por TIOCGPTNser la número 2.

open("/dev/ptmx", O_RDWR)               = 5
...
ioctl(5, TIOCGPTN, [2])                 = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0

Pero no pudo reconocerlo. No sé por qué ese chown fallaría, pero el fallo del chown da una razón plausible por la cual la pantalla se rindió. Puede obtener un poco más de información agregando -va las opciones de strace y mirando statdespués TIOCGPTNpara ver quién posee la /dev/pts/entrada.

Una de las posibles razones de ese error: políticas incorrectas de selinux, pero de acuerdo con redhat bugtracker, dichos errores se corrigieron en fedora 17/18.

Como solución alternativa, puede cambiar la variable SCREENDIRen usted ~/.bashrca algo así $HOME/.screen.

Cuando encontré este mensaje de error. Tuve que ajustar mis permisos con lo siguiente:

chmod 2775 /usr/bin/screen

Y esto resolvió el problema para mí. El 2 es muy importante para los permisos de acceso correctos.

Debería leer más sobre SUID, SGID, Sticky Bit, ACL y cómo afectan el acceso.

El comando de pantalla ya se estaba ejecutando. Así que lo terminé y volví a escribir el comando. Sí, esta no es una resolución bastante buena como otras, pero lleva menos tiempo hacer esto.

Simplemente ps y encuentre el pid, elimine el PID y continúe con volver a escribir el comando de pantalla.

Si está ejecutando múltiples comandos de pantalla, asegúrese de finalizar el proceso correcto asociado con su terminal.

Encontré este problema resuelto después de comentar la siguiente línea en / etc / fstab y reiniciar:

devpts         /dev/pts        devpts  defaults        0       0

Asegúrese de que nadie más screenesté usando ese dispositivo

Esto se puede lograr con /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

Y luego elimine ese proceso si ese es el caso.

Por alguna razón, bajo esta condición, sudo screenaún puede acceder al dispositivo, pero esa conexión perderá caracteres, que son consumidos por el otro screen.

Asegúrese de que el usuario tenga permiso de lectura y escritura para el archivo

Por ejemplo, en Ubuntu desea agregar el usuario al dialoutgrupo: /ubuntu//a/133244/52975

Obtuve exactamente el mismo problema y una salida strace bastante similar.

Esto lo solucionó:

sudo chmod u+s /usr/bin/screen
sudo chmod 755 /var/run/screen

créditos: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/