Por que recebo "a tela está terminando" sem raiz?

Eu instalei a tela no Fedora 19. Quando eu testo o comando como root remotamente através do SSH, ele funciona perfeitamente. Por exemplo, se eu entrar, screenum novo emulador de terminal é iniciado e aguarda comandos. Eu posso desanexá-lo etc. No entanto, quando tento fazer o mesmo depois de logado remotamente através do SSH como um usuário padrão, o comando termina imediatamente. A única mensagem que vejo é [screen is terminating].

Alguém já teve esse problema? Está relacionado a permissões incorretas?

Atualizar:

$ 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 +++

Tentei alterar as permissões para 777, mas quando executo screen, recebo:

O diretório '/ var / run / screen' deve ter o modo 775.

Portanto, reverti minhas alterações.

O flip-flopping entre "deve ter o modo 777" e "deve ter o modo 775" é causado por strace.

screengeralmente é um programa setuid ou setgid. Ele obtém privilégios extras quando é executado, usado para criar arquivos de soquete e / ou modificar o utmp.

Quando um processo está sendo rastreado, setuid e setgid são desativados. O processo de rastreamento, controlado pelo usuário menos privilegiado, pode assumir o processo rastreado, portanto ele deve ser executado sem seus privilégios extras para evitar fornecer muita energia ao usuário original.

screen detecta se está sendo executado com privilégios setuid, privilégios setgid ou nenhum, e ajusta sua expectativa das permissões do diretório de acordo.

Portanto, isso cria uma classe de problemas que não podem ser facilmente depurados strace.

Mas se você é root, existe uma solução alternativa! Se o processo de rastreamento estiver em execução como raiz, ele poderá obter privilégios normalmente. Então, aqui está o que você faz:

1. Abra 2 novos terminais
2. No primeiro terminal, efetue login na máquina remota como root
3. No segundo terminal, efetue login na máquina remota como usuário normal
4. Use pspara obter o PID do processo de shell do usuário normal no segundo terminal
5. No primeiro terminal, execute strace -f -p SHELLPID
6. No segundo terminal, execute a tela e observe-a falhar
7. No primeiro terminal, agora você tem o log de rastreamento necessário para descobrir o que está realmente errado.

A adição de chave ao stracecomando é a -fopção, que informa para rastrear processos filho. Você precisa dele para rastrear a tela que será filha do processo de shell especificado -p.

Também gosto de usar -ffe especificar um arquivo de saída com -o, como em

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

que criará um arquivo de saída separado para cada processo filho. Depois você as lê less /tmp/screentrace*e o resultado geralmente é mais limpo do que o que você obtém usando uma única -f.

ATUALIZAR

Agora que eu vi a saída do strace, não sei exatamente o que deu errado, mas essa linha é a coisa mais surpreendente no rastreamento:

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

Algumas linhas antes, ele criou um pty, que foi revelado TIOCGPTNcomo o 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

Mas foi incapaz de chown. Não sei por que esse chown falharia, mas o fracasso do chown fornece uma razão plausível para que a tela desista. Você pode obter um pouco mais de informações adicionando -vàs opções de rastreio e examinando o statdepois TIOCGPTNpara ver quem é o proprietário da /dev/pts/entrada.

Por várias razões possíveis para esse erro - políticas selinux incorretas, mas de acordo com o redhat bugtracker, esses erros foram corrigidos no fedora 17/18.

Como solução alternativa, você pode alterar a variável SCREENDIRem você ~/.bashrcpara algo como $HOME/.screen.

Quando eu encontrei essa mensagem de erro. Eu tive que ajustar minhas permissões com o seguinte:

chmod 2775 /usr/bin/screen

E isso resolveu o problema para mim. O 2 é muito importante para as permissões de acesso corretas.

Você deve ler mais sobre SUID, SGID, Bit Sticky, ACL e como eles afetam o acesso.

O comando de tela já estava em execução. Então eu terminei e redigitei o comando. Sim, essa não é uma resolução muito boa como outras, mas leva menos tempo para fazer isso.

Apenas ps e encontre o pid, mate o PID e prossiga com redigitando o comando da tela novamente.

Se você estiver executando vários comandos de tela, certifique-se de encerrar o processo correto associado ao seu terminal.

Encontrei esse problema resolvido depois de comentar a seguinte linha no / etc / fstab e reiniciar:

devpts         /dev/pts        devpts  defaults        0       0

Verifique se nenhum outro screenestá usando esse dispositivo

Isso pode ser alcançado com /superuser/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :

sudo lsof /dev/ttyS0

E então mate esse processo, se for o caso.

Por alguma razão, sob essa condição, sudo screenainda é possível acessar o dispositivo, mas essa conexão perderá caracteres que são consumidos pelo outro screen.

Verifique se o usuário possui permissão de leitura e gravação no arquivo

Por exemplo, no Ubuntu, você deseja adicionar o usuário ao dialoutgrupo: /ubuntu//a/133244/52975

Eu tenho exatamente o mesmo problema e uma saída strace bastante semelhante.

Isso corrigiu:

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-immedately-4175444530/