sessão tmux morta ao desconectar do ssh

Question

Resumo : Estou tentando descobrir por que minha sessão tmux morre quando eu me desconecto do ssh

Detalhes :

Eu tenho o tmux instalado em um sistema Arch Linux. Quando inicio uma sessão do tmux, posso desanexá-la e, em seguida, anexar novamente enquanto a sessão do ssh estiver ativa. Mas se eu terminar minha sessão ssh, a sessão do tmux será morta.

Eu sei que este não é o comportamento normal porque eu tenho outro sistema onde a sessão do tmux continua rodando mesmo se a sessão do ssh estiver terminada e eu posso me conectar à sessão do tmux após estabelecer uma nova conexão ssh. O sistema que tem um problema e o que funciona corretamente tem configurações muito semelhantes, então não tenho certeza do que verificar.

Estou executando o tmux versão 1.9a. O sistema que tem um problema (que eu tenho acesso root para) tem uma versão do kernel Linux 3.17.4-1 e o sistema que funciona corretamente tem a versão do kernel 3.16.4-1-ARCH (eu não tenho raiz nisso) sistema). Eu duvido que a versão do kernel seja a fonte do problema, essa é apenas uma diferença que notei.

Eu pensei em perguntar se alguém viu um problema semelhante e sabe de uma possível solução.

Os passos precisos que levam ao problema são:

1. ssh para usinar
2. execute tmux para iniciar o tmux
3. ctrl-B D para desanexar (neste ponto eu pude reconectar com tmux attach
4. feche a sessão ssh (neste momento a sessão do tmux está morta, eu pude observar isso quando estou logado como root em um terminal diferente)
5. reconecte-se com ssh e execute tmux attach e receberei a mensagem no sessions e executando tmux ls returns failed to connect to server: Connection refused . Isso faz sentido porque o saque não está sendo executado. O que não faz sentido para mim é porque é morto na etapa 4 quando eu me desconecto da sessão ssh.

dados strace:

Em resposta a um dos comentários, usei o strace para ver o que o sistema chama o processo do servidor tmux. Parece que quando eu saio da minha sessão ssh (digitando exit ou com ctrl-d ) que o processo tmux está sendo eliminado. Aqui está um trecho da parte final da saída strace.

poll([{fd=4, events=POLLIN}, {fd=11, events=POLLIN}, {fd=6, events=POLLIN}], 3, 424) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
sendto(3, "", 1, 0, NULL, 0)         = 1
+++ killed by SIGKILL +++

Eu comparei isso com um sistema diferente, no qual o tmux funciona corretamente e, nesse sistema, o processo tmux continua em execução, mesmo depois de eu sair. Então a causa raiz parece ser que o processo tmux está sendo finalizado quando eu fecho a sessão ssh. Preciso gastar algum tempo para solucionar esse problema, mas pensei em atualizar minha pergunta, pois a sugestão de strace era útil.

    

Answer 1

Teoria

Alguns sistemas init, incluindo o systemd, fornecem um recurso para eliminar todos os processos pertencentes ao serviço. O serviço geralmente inicia um único processo que cria mais processos por bifurcação e esses processos também podem fazer isso. Todos esses processos são tipicamente considerados parte do serviço. No systemd isso é feito usando cgroups .

No systemd, todos os processos pertencentes a um serviço são eliminados quando o serviço é interrompido por padrão. O servidor SSH é obviamente parte do serviço. Quando você se conecta ao servidor, o servidor SSH geralmente se bifurca e o novo processo manipula sua sessão SSH. Ao se dar conta do processo de sessão do SSH ou de seus filhos, outros processos do lado do servidor são iniciados, incluindo sua tela ou tmux .

Killmode e ativação de soquete

O comportamento padrão pode ser alterado usando a diretiva KillMode . O projeto upstream não inclui todos os arquivos .service e, portanto, estes variam por distribuição. Normalmente, existem duas maneiras de ativar o SSH no seu sistema. Um é o clássico ssh.service que mantém um daemon SSH de longa duração escutando na rede. O outro é via ativação de soquete manipulado pelo ssh.socket que, por sua vez, inicia [email protected] , que é executado apenas para uma única sessão SSH.

Soluções

Se seus processos forem mortos no final da sessão, é possível que você esteja usando a ativação de soquete e seja morto pelo systemd quando perceber que o processo de sessão SSH foi encerrado. Nesse caso, existem duas soluções. Uma é evitar o uso da ativação de soquete usando ssh.service em vez de ssh.socket . A outra é definir KillMode=process na seção Service de [email protected] .

A configuração KillMode=process também pode ser útil com o clássico ssh.service , pois evita a morte do processo de sessão SSH ou dos processos tela ou tmux quando o servidor é interrompido ou reiniciado.

Notas futuras

Esta resposta aparentemente ganhou um nível de popularidade. Embora funcionasse para o OP, pode acontecer que ele não funcione para alguém no futuro, devido ao desenvolvimento ou configuração do systemd-logind . Por favor, verifique a documentação em sessões de log-in se você tiver um comportamento diferente da descrição nesta resposta.

    

Answer 2

Você usa systemd com ativação de soquete para SSH?

Nesse caso, há um problema conhecido com esse . De acordo com os proponentes do systemd, isso é realmente um recurso - systemd mata todos os processos gerados por uma sessão quando a sessão termina. (Eu posso ver isso sendo útil, mas no caso do GNU screen , ou tmux , você definitivamente não quer isso ☺ nem na maioria dos outros casos em que os usuários podem executar processos em segundo plano, claro.)

Em caso afirmativo, tente mudar de sshd.socket para sshd.service .

    

Answer 3

Eu estava tendo o mesmo problema com o tmux e a tela no Ubuntu 16.04 (kde neon). Quando a sessão ssh foi desconectada, o screen / tmux foi terminado.

longa história, o systemd alterou sua configuração padrão para killuserprocess = yes, portanto, após deixar uma sessão ssh, todo processo criado por ela será encerrado.

Correção fácil (depois de horas de tentativas) execute screen / tmux usando este comando

Para a tela

systemd-run --scope --user screen

para o Tmux

systemd-run --scope --user tmux

Você pode criar um alias para facilitar

alias tmux= "systemd-run --scope --user tmux"

    

Answer 4

Outra solução para isso, que não requer a transferência de sshd.socket para sshd.service , é iniciar tmux server como um serviço systemd [0]. Dessa forma, o servidor tmux já está em execução quando você executa o SSH no servidor, em vez de ser gerado pelo comando tmux no SSH, portanto, não será eliminado.

[0] link