“Servidor recusou alocar pty” - como montar os devpts automaticamente?

Question

Eu tenho usado essa caixa do ubuntu 16.04 hospedada no vSphere todos os dias úteis durante o último meio ano. Estou me conectando a ele do Windows com putty / kitty. Hoje, fui recebido pela mensagem semelhante a um em esta questão .

Não sei o que causou isso. Aqui está a mensagem:

Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)

                                                                   * Documentation:  https://help.ubuntu.com
                                                                                                             * Management:     https://landscape.canonical.com
                                                                                                                                                               * Support:        https://ubuntu.com/advantage

                                                                                                                                                                                                             0 packages can be updated.
                                                                                                                                                                                                                                       0 updates are security updates.

Eu preservei a formatação impressa.

Esta resposta resolve o problema, mas eu tenho que digitar o comando dado a cada reinicialização:

mount devpts /dev/pts -t devpts

Adicionando uma linha fstab conforme mostrado no link também fornecido em um das respostas da pergunta original não parece mudar nada.

Para ser honesto, não tenho ideia de por que não precisei montar este dispositivo até agora e, de repente, ele parou de funcionar e eu preciso dessa montagem.

Qual é a maneira correta de corrigir esse problema para que eu não precise montá-lo depois de cada reinicialização manualmente? Prazer em fornecer registros ou outros diagnósticos que você possa solicitar.

Atualizar

Então, inicialmente eu lidei com o problema reconstruindo a caixa, mas agora aconteceu novamente e começou a acontecer com outras máquinas que eu também gerencio.

Para seguir a resposta de Filipe .

Executando gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts dá

mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true

Executando gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move dá

# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev

A execução com a opção "debug" dá essa saída .

Algo mais que eu possa fazer para encontrar a causa raiz do problema?

A regeneração com sudo update-initramfs -c -k $(uname -r) não produziu nenhuma alteração visível após a reinicialização.

Isto é o que eu posso ver no mtab antes e depois de montar os devpts manualmente:

>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
>sudo mount devpts /dev/pts -t devpts
>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0

    

Answer 1

O sistema de arquivos / dev / pts é geralmente montado pelo initrd (a.k.a. initramfs) no Ubuntu.

O initramfs é um pequeno sistema de arquivos que é carregado na memória quando o kernel inicializa e configura o sistema para alternar para o sistema de arquivos raiz real, após configurar os fundamentos básicos e carregar quaisquer drivers do kernel necessários para montar a raiz real. p>

Você pode encontrá-lo em / boot, chamado initrd.img- *, onde a última parte corresponde à versão do kernel.

É um arquivo cpio comprimido em xz.

Você pode olhar dentro do script "init" que é executado pela primeira vez quando é montado usando o seguinte comando. O "grep" no final dele olha para a linha que monta os devpts:

$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts
mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true

Na verdade, os devpts são montados na raiz do initramfs, portanto, mais tarde, há outro passo que o move para a raiz real antes de mudar para ele. Você pode ver aqui:

$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev

Se você quiser extrair todo o conteúdo do initrd, você pode usar:

# First go to an empty directory
$ mkdir -p /tmp/extract_initrd
$ cd /tmp/extract_initrd
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -id

E depois explore essa árvore ...

Se parecer que algo está errado com o seu initramfs, você pode tentar gerá-lo novamente usando o comando update-initramfs , assim:

$ sudo update-initramfs -c -k $(uname -r)

Cuidado com os erros na saída deste comando, eles podem lhe dar uma pista de algo que pode estar errado ...

Outra possibilidade é habilitar o log de depuração no initrd. Para fazer isso, adicione "debug" à linha de comando do kernel e reinicie. Em seguida, examine o arquivo /run/initramfs/initramfs.debug após a inicialização do sistema, que conterá as mensagens impressas pelos scripts initrd. Veja aqui para mais detalhes sobre a depuração do initramfs.

    

Answer 2

Eu tive um problema parecido no link

As permissões eram diferentes das esperadas, mas foram capazes de corrigir isso usando:

sudo mount -o remount /dev/pts
sudo grep devpts /proc/mounts

devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

    

Answer 3

Quando eu estava recebendo "Servidor se recusou a alocar pty" era um problema muito mais simples: meu servidor SSH tinha a opção 'PermitTTY' definida como 'não'. (Nas versões mais recentes do OpenSSH, essa linha normalmente é comentada porque 'yes' é o padrão. Portanto, contanto que não seja definido manualmente como 'no', você deve ser bom.)

Use o seu editor favorito para verificar novamente o arquivo sshd_config.

sudo nano /etc/ssh/sshd_config

Certifique-se de que a linha 'PermitTTY' esteja ausente, comentada ou configurada manualmente como 'yes', depois reinicie seu servidor SSH.

sudo service sshd restart

Isso pode ser tudo o que você precisa.