Processo morto em desconexão ssh apesar de screen / nohup

1

Estou enfrentando uma situação bastante estranha:

  • ssh para um beaglebone (detalhes: uname -a="Linux beaglebone 3.2.34 # 1 quarta-feira 21 de novembro 14:17:11 CET 2012 armv7l GNU / Linux", servidor ssh: Dropbear sshd v2012.55)
  • inicie qualquer tipo de processo pela tela, ou nohup ou /etc/init.d /
  • logout
  • re-ssh para ele
  • observe que o processo não está mais lá ..

Ao usar uma segunda conexão ssh, posso observar que o processo iniciado é eliminado na desconexão.

Eu vi postagens como O que determina exatamente se um job em segundo plano é eliminado quando o shell é encerrado ou é eliminado? , mas ainda não é possível entender esse comportamento, que claramente não é o caminho screen e outros processos conhecidos devem funcionar.

$ shopt huponexit
huponexit       off

Eu tive que recorrer ao uso de comandos do cron para persistir o processo

Por que os processos desconectados são mortos na desconexão?

Você vê outras coisas para procurar?

    
por NotSqrt 06.06.2014 / 14:22

1 resposta

0

Parece estranho nohup não funciona, mas isso pode ser facilmente testado, como segue:

  { sleep 999; echo $? > exitcode ; } &
  fuser -1 -k /bin/sleep
  expr $(cat exitcode) - 128

Isso imprimirá o código de retorno menos 128, que é exatamente o número do sinal que o matou. Você pode listá-los simplesmente fazendo:

  kill -l 

Agora tente isso:

  rm exitcode
  { nohup sleep 999; echo $? > exitcode; } &
  fuser -1 -k /bin/sleep
  ls -l exitcode

Se nohup funcionar, neste momento você será informado de que não existe tal arquivo. Você pode verificar isso ao fazer:

  fuser -15 -k /bin/sleep
  expr $(cat exitcode) -128

e encontrando este valor como 15.

EDITAR

Seu último comentário foi bastante revelador: significa que o SIGHUP não é enviado para o processo (suspenso, neste caso), mas diretamente para o seu shell. Isso pode ser feito apenas por Dropberar, é claro. Uma pequena pesquisa mostrou que o Dropbear realmente mata todos os processos do usuário no logoff.

Você pode ativar esse recurso chato adicionando a linha

 KillMode=process

no final da sub-rotina Service no arquivo /lib/systemd/[email protected]. Em seguida, reinicie ou reinicie o Dropbear.

    
por 06.06.2014 / 15:09