☰

Sem nohup no csh, o trabalho em segundo plano ainda está em execução após a saída do ssh

tag-icon • tag-icon linux ssh signals csh nohup
Sem nohup no csh, o trabalho em segundo plano ainda está em execução após a saída do ssh

Estou tentando entender a necessidade de usar nohupcomandos em segundo plano no ssh. Meu shell é csh no CentOS.

  1. O comando em segundo plano abaixo continua em execução mesmo após a saída do ssh. Eu esperava que isso só acontecesse se nohupestivesse prefixando o comando.

    Qual é o cenário onde nohupseria necessário?

     ssh host 'sleep 80 >& /dev/null &'

  2. Também tentei um shell interativo, e o PID do trabalho em segundo plano ainda existe no host após a saída do ssh.

     ssh host sleep 80 >& /dev/null & exit

  3. Também tentei encerrar a sessão interativa com kill -HUP PIDem vez de exit, e o PID do trabalho em segundo plano ainda existe no host após a saída do ssh.

Estou fazendo alguma coisa errada?

Responder1

Não, umfundoo grupo de processos (trabalho) NÃO é eliminado por padrão quando o líder da sessão (o shell) sai ou quando seu terminal de controle é desativado.

Existem apenas alguns casos especiais em que isso acontece:

(1)O trabalho em segundo plano éparou, caso em que será enviado um SIGHUP/ SIGCONTpar de sinais pelonúcleo. Se o SIGHUPsinal não for capturado ou ignorado por um processo, o processo será encerrado.

A definição de trabalho interrompido é: qualquer trabalho que contenha um processo interrompido. Um processodormindoem uma chamada de sistema de bloqueio como nanosleep(2)ou read(2)NÃO é considerada interrompida.

(2)Um processo tenta ler ou escrever no terminal que não existe mais e sai (por sua própria vontade) devido aos erros que obtém ao tentar fazê-lo.

(3)O trabalho é na verdade umprimeiro planotrabalho. Onúcleoenvia um SIGHUPsinal para o grupo de processos em primeiro plano quando o processo líder/controlador da sessão (ou seja, o shell) termina. O próprio processo de controle é sinalizado SIGHUPquando seu terminal de controle é desmontado, o que geralmente faz com que ele seja encerrado.

Mesmo os comandos iniciados &fazem parte doprimeiro planogrupo de processos quando eles são iniciados a partir de um shell sem controle de trabalho (que na maioria dos shells --mas não em csh-- é o padrão ao executarroteirosesubcamadas).

(4)Você está usando um shell como bashor zsh, que se esforça para enviar um SIGHUPsinal para todos os seus trabalhos quando ele próprio é sinalizado SIGHUP(de acordo com o ponto 3. acima, o shell é o processo de controle) ou simplesmente quando ele sai (o último apenas o padrão em zsh, mas não o padrão e sujeito à shopt huponexitopção em bash).

Oshell csh(seja o real cshou tcsh)não tem esse comportamentode bashou zsh. Em tcsh(mas NÃO no real csh), você pode iniciar um comando com o hupbuiltin para que ele seja ativado quando o shell sair:

tcsh% hup sleep 3600 &
tcsh% exit
$ pgrep sleep
[nothing]

(5)Seu sistema init faz de tudo para limpar qualquer sessão de usuário encerrada. Em sua configuração padrão,sistemasinalizará todos os processos de umescopocom um SIGTERMseguido por um SIGKILLapós um atraso, então nohupNÃO irá ajudá-lo com isso de qualquer maneira. Além disso, a ideia do systemd de umescoponão corresponde a uma sessão de processo Unix, portanto, executar um comando with setsid(1)também não permitirá que ele escape.

Você provavelmente pode alterar o comportamento do systemd alterando seus padrões KillUserProcesses=yes, as opções KillMode=control-group, KillSignal=SIGTERMe .SendSIGKILL=yes

informação relacionada