Pode-se acessar um terminal aberto no computador via SSH?

Question

Estou procurando acessar um terminal aberto , ou seja, aberto localmente em minha máquina, de um computador remoto sem usar tmux ou screen . Há algumas razões para isso, a mais simples das quais é que eu continuo chegando a uma situação em que eu não planejei com antecedência, executei algo grande no meu pc no trabalho, fui para casa e depois quis verificá-lo via ssh.

Essencialmente, estou procurando uma maneira de anexar ao terminal já em execução em um computador e ver sua saída.

Agora, eu sei que existem alguns tópicos que dizem que você não pode fazer isso (como ), e outros que simplesmente recomendam screen e tmux (como este , este ou esse aqui ). O que estou procurando é uma maneira de diretamente acessar um processo de terminal em execução ou, no mínimo, ver a saída em cache desse terminal. Eu não preciso necessariamente ser capaz de inserir comandos nesse terminal.

Existe uma maneira de fazer isso? Caso contrário, alguma idéia em um hack que poderia funcionar? Eu estava pensando que eu provavelmente poderia encontrar uma maneira de logar automaticamente stdout, stderr e os comandos para um arquivo (talvez um ajuste inteligente no histórico bash que registra tudo?)

    

Answer 1

Simplesmente devido a como os terminais são construídos, não é possível acessar tudo , ou seja, você não pode visualizar um terminal em execução e interagir com ele se não tiver uma sessão destacável em execução dentro do terminal mencionado, como screen ou tmux session, ou se você não tiver iniciado esse comando com o log por meio do comando script .

O que pode ser feito é parcialmente visualizar TTY via comando sudo cat /dev/vcs1 . /dev/vcs[1-6] corresponde aos seus respectivos consoles TTY. Isso é limitado pelo tamanho do buffer de rolagem do respectivo TTY, o que significa que você só pode ver o que estiver guardado na memória até certo número de linhas. Isso, claro, pode ser ajustado para aumentar o número de linhas, como mostrado na resposta do muru aqui . Alternativamente, você provavelmente deveria tentar

setterm -file log.txt -dump [ttynumbers]

que foi mencionado em esta questão ssh .

No final do dia, o bodhi.zazen anotou corretamente em seu comente , que a sua recusa em usar screen ou tmux é o maior problema. Eu entendo totalmente, muitas vezes esqueço de acompanhar programas de longa duração, mas com alguns comandos você deve começar a pensar no futuro.

    

Answer 2

Como você marcou essas gnome-terminal , dependendo da versão, pode ser possível visualizar parte da saída. De esta postagem do blog , onde o autor queria ver o que o Terminal do GNOME faz Rolagem "ilimitada":

  

Eu poderia apenas ver quais arquivos gnome-terminal tinham aberto, então lsof   para o resgate. Então eu achei que estava sendo sorrateiro, tinha um número de   arquivos chamados /tmp/vteXYZ1tv open, mas eles já haviam sido deletados.   Assim, você não pode vê-los durante a navegação e eles serão removidos quando   o programa fecha. [...] Eles podem ser restaurados, do meu jeito   são provavelmente outros), foi fazer um ls -l /proc/<gnome-terminal pid>/fd   para ver o que eles apontam. Então você pode cat estes para fazer um   novo arquivo. Estas são apenas uma cópia literal da saída do terminal. Não   compressão. Não há nada.

Mas em versões mais recentes, os arquivos devem ser criptografados. De esta resposta :

  

vte-0.40 (que provavelmente aparecerá no Ubuntu 15.10 W.W.)   comprimir e criptografar esses arquivos. Isso reduzirá a necessidade   armazenamento para aproximadamente 1/4 do seu tamanho (se seu aplicativo produzir X   quantidade de dados como texto simples, em algum lugar entre X / 4 .. X / 3 é um   estimativa razoável para o armazenamento que será necessário), e também   livra-se do problema de privacidade / segurança no caso de alguém obter acesso bruto   para o disco rígido.

Se você quer apenas resultados futuros, você pode tentar arrastar o processo para um novo TTY usando o reptyr .

    

Answer 3

Dos comentários, existem várias soluções possíveis, mas todas elas precisam ser implementadas ANTES de você executar o comando no terminal gráfico.

Por exemplo, consulte o link

Assim, os usuários da mesma sessão X não podem se reconectar a guias fechadas.

Você pode tentar o reptyr como sugerido pelo muru, e esta é uma solução legal, mas é melhor planejar suas sessões de ssh melhor desde o início.

Você precisa desenvolver uma estratégia de trabalho melhor.

1. Use tela ou tmux ou similar. Essas ferramentas foram projetadas exatamente para esse cenário.

Pessoalmente eu uso tela como eu estou familiarizado com ele e pelas razões que você afirma eu sempre uso uma sessão de tela sobre ssh, ou seja, eu começo a tela e verver realmente sair da sessão de tela. Muitas vezes, tenho mais de uma sessão de tela, uma para cada VM em um host, por exemplo.

2. Use um servidor VNC. Você pode executar a sessão por ssh (VNC-over-SSH) ou usar o FreeNX, que é mais rápido e seguro. NÃO EXECUTE UM SERVIDOR VNC SOBRE "A INTERNET" SEM SSH OU FREENX

VNC sobre ssh - link

FreeNX - link

3. Você pode usar o Xpra

link

link

Com o xpra você pode iniciar e reconectar o terminal gráfico, mas novamente você precisa estar executando o xpra antes de iniciar o terminal.

    

Answer 4

Dependendo do processo executado dentro do terminal, você pode ter sucesso observando o estado e as ações feitas por esse processo em vez do que foi exibido no terminal.

Alguns exemplos, supondo que você tenha de alguma forma descoberto o PID (ID do processo) do processo em questão (por exemplo, usando pidof ou ps ):

• Se a ferramenta em questão iniciar subcomandos um por um, verifique qual deles está em execução usando ps .

• Se a ferramenta fornecida às vezes alterar seu diretório de trabalho, verifique isso em /proc/<PID>/cwd .

• Se a ferramenta especificada operar em vários arquivos seguidos, verifique qual deles está em /proc/<PID>/fd . Se você não consegue ver nenhuma no momento, pode ser que o seu processo tenha acabado de fechar um e esteja prestes a abrir o próximo; verifique novamente algumas vezes o conteúdo desse diretório.

• Se o comando operar em um único arquivo enorme usando o padrão read / write syscalls, você poderá encontrar o número do descritor de arquivo em /proc/<PID>/fd e verificar o deslocamento atual no arquivo correspondente em% código%. Se o comando usar /proc/<PID>/fdinfo / pread , consulte o próximo ponto.

• Você pode se conectar ao processo usando pwrite para ver o que está fazendo: strace . Sair pouco depois usando Ctrl + C (termina apenas strace -p <PID> , não o aplicativo que você está rastreando). Examine a saída e procure por material relevante que possa lhe dar uma ideia. Use por exemplo a opção strace para restringir essa saída somente às operações de arquivo. Você verá por exemplo os nomes de arquivos que estão sendo abertos pelos seus aplicativos, bem como os deslocamentos em que as operações -e trace / pread acontecem.