Por que “su -c command &” aparentemente permite que um comando seja executado em segundo plano sem desligar?

Question

Eu estava ajudando um colega que estava tendo problemas com um processo de segundo plano morrendo intermitentemente.

Descobri que eles estavam iniciando o processo em segundo plano fazendo login no servidor e executando:

su - <user> -c '<command>' &

"Aha", eu exclamei. "Se você iniciar um comando com" & "ele irá desligar quando você sair do terminal de controle. Você precisa usar algo como nohup para conseguir isso. Realmente este processo precisa suportar a execução como um daemon, tut tut."

Nós testamos o comando acima para demonstrar meu ponto e ... pareceu funcionar: o processo iniciado pelo comando não saiu quando saímos do terminal que executava o comando acima. / p>

comando é um script Python personalizado cuja saída vai para um arquivo. Tanto quanto eu posso dizer não há "daemonize" inteligente como recurso no script. Ele não faz nenhuma das coisas necessárias para ser executado como daemon listado 1

A execução do comando da maneira como se comporta da maneira esperada:

<command> &
exit

No caso acima, o processo em segundo plano iniciado pelo comando é encerrado quando saímos do terminal.

Minha pergunta é esta:

1. O que está acontecendo quando adicionamos "su -c &" que impede o processo de sair quando o nosso terminal sai. Eu gostaria de entender em detalhes com relação ao terminal de controle, entrada e saída padrão, etc.

2. Essa é uma maneira razoável de atingir o objetivo de executar esse comando como um processo em segundo plano. Se não porque, não?

Eu quero propagar as melhores práticas dentro da minha empresa, mas preciso demonstrar e fazer o backup de todas as recomendações que eu fizer.

Além disso, só quero entender o que está acontecendo exatamente.

    

Answer 1

Existem várias maneiras de um processo ser morto por causa de um terminal que está morrendo.

1. A primeira maneira é que o driver de terminal no kernel envia um sinal SIGHUP para o processo de controle para o qual o terminal é o terminal de controle . Na maioria dos casos, o processo de controle é o shell que é inicialmente iniciado no terminal, e seu terminal de controle é aquele ao qual seus stdin, stdout e stderr estão conectados. Um processo se desconecta do terminal de controle se ele chamar setsid .

2. A segunda maneira é que o shell, quando recebe SIGHUP, reenvia esse sinal para seus subprocessos - mais precisamente, para seus jobs em segundo plano. Algumas shells (ksh, bash, zsh) têm um disown embutido para dizer ao shell para não enviar um SIGHUP para um trabalho em particular.

3. Se o terminal desaparecer e um programa tentar ler a partir dele, ele será notificado sobre uma condição de fim de arquivo (ou possivelmente EIO para um trabalho em segundo plano). Se o terminal desaparecer e um programa tentar gravar nele, a gravação retornará com um erro de EIO. Isso pode fazer com que o programa seja encerrado.

Então, o que su muda aqui é que (2) normalmente faria com que o shell inicial matasse o job em segundo plano, mas como esse processo em segundo plano está sendo executado como um usuário diferente, o sinal não pode ser entregue e o processo em segundo plano em.