Efetuando login no ssh em uma sessão diferente?

2

Eu não sei exatamente qual é o termo correto, mas percebo que se eu fizer login em um servidor SSH remoto, feche a janela, abra um novo e faça login nesse servidor novamente, meu histórico bash e usuário processos parecem ser diferentes. Por exemplo, se eu iniciei um processo em segundo plano, não posso voltar a usá-lo, ou algo que eu digitei não aparecerá no meu histórico bash.

O problema é que, por algum motivo, ocasionalmente, algo acontece na minha sessão remota e, em vez de ser desconectado, a sessão é interrompida; Eu tenho que fechar a janela e abrir um novo para se reconectar. Como resultado, às vezes, significa que um processo de longa duração é basicamente "perdido", já que não consigo voltar a ele.

Existe alguma maneira de configurá-lo para que, quando eu fizer login novamente, faça o login novamente na mesma "sessão"?

Isso está usando o Terminal OS X.

    
por Jordan Reiter 11.11.2013 / 18:00

2 respostas

4

Quando você efetua login na máquina remota, o sshd ali aloca um pseudo-terminal e inicia seu shell de login. Quaisquer processos iniciados, em segundo plano ou em primeiro plano, são processos filhos desse shell. (Leia "fork", "parent process" e "child process"; use o comando "pstree" para ver o estado do sistema).

Se você desconectar, por exemplo, fechando seu cliente, o sshd fechará o pseudo-terminal. Isto irá (indiretamente, ler em "terminal de controle" e "líder de sessão") terminar o processo de shell, o que faz com que seus filhos terminem ou, porque seu pai agora está desaparecido, seja reparado em init . (Leia o "sinal HUP" - deve estar em qualquer um dos materiais do terminal de controle que você encontrar - e o comando nohup ).

Quando você se conecta novamente, o sshd aloca um novo pseudo-terminal e inicia uma nova instância do seu shell de login. Não existe nenhum mecanismo para obter os processos anteriormente em execução - assumindo que eles ainda estão sendo executados - anexados a este shell (se houvesse, cada programa precisaria saber como lidar com processos filhos aparecendo espontaneamente que poderiam compartilhar o padrão entrada / saída e assim por diante; um "shell" é um processo especial apenas para você, o usuário, não no que diz respeito ao sistema).

A única maneira de fazer isso é usar um programa como screen ou tmux (pode haver outros). Estes são essencialmente um processo de servidor que gerencia seus próprios pseudo-terminais com shells e qualquer outra coisa e um processo de cliente que possa exibir o conteúdo desses usuários para você e enviar sua entrada para eles; quando você se desconecta, esse processo do cliente morre, mas quando você se reconecta, pode iniciar um novo - o servidor ainda estará em execução.

(Existem algumas simplificações acima, mas isso deve ajudá-lo a entender o que realmente está acontecendo. Leia o "pseudo-terminal".)

    
por 11.11.2013 / 19:34
0

Bem, na verdade, não há como recuperar sua sessão , o que você pode recuperar é o seu histórico.

Para fazer isso (no bash), você tem que incluir (ou alterar) uma linha em seu .bash_profile em seu diretório home para dizer bash para salvar seus comandos digitados:

export HISTSIZE=1000 # to keep a thousand commands in history
export HISTCONTROL=ignoreboth # to prevent some strange behaviors

Então, todos os comandos, até que sejam alcançados mil, são anotados no arquivo .history, você pode ver os últimos digitando

history

Pesquise pressionando Ctrl + R seguido por uma parte do comando que você deseja recuperar.

Deixe-me dizer que esse histórico está no disco de servidores, portanto, se você estiver em um servidor compartilhado, os outros comandos de usuários devem estar no mesmo arquivo de histórico e, assim, você verá os comandos deles em vez de algumas vezes, Ctrl + R deve resolver este problema.

PS: para aplicar essa resposta, certifique-se de estar rodando dentro do bash, apenas digite

ps

e procure por um bash em algum lugar na tela. Assim:

  PID TTY          TIME CMD
24165 pts/3    00:00:00 bash
24169 pts/3    00:00:00 ps

e você pode aprender muito mais em

man bash

Mas isso levaria muito tempo para ler.

    
por 11.11.2013 / 23:05