Qual é o comportamento de um processo rejeitado sobre a gravação SSH para stdout quando a sessão SSH é perdida?

Question

Eu tenho um aplicativo que processa solicitações HTTP e imprime determinadas informações sobre a solicitação, conforme ela é processada em stdout . Nesse cenário, executei disown -h e disown no processo, depois de aplicá-lo em segundo plano. Ainda continua a imprimir para stdout , o que é esperado. Além disso, esse processo é iniciado em uma sessão SSH. Suponha que eu tenha acesso à Internet esquisito e, após fazer todos os itens acima, a conexão seja interrompida, sem que o SSH esteja ciente de que isso ocorreu. Naturalmente, isso leva alguns instantes antes que o SSH esteja ciente de que a conexão foi interrompida.

Durante esse tempo, o aplicativo começa a passar por tempos limite ao processar solicitações, até que a sessão SSH realmente morra. Isso é devido a problemas de buffer envolvendo sua gravação em stdout quando o PTY não existe mais?

    

Answer 1

disown impedirá que seu aplicativo receba um sinal SIGHUP quando o SSH sair. No entanto, se o aplicativo gravar posteriormente em um artigo que foi revogado, ele receberá um sinal SIGPIPE . A menos que você esteja manipulando ou ignorando SIGPIPE , ele matará seu aplicativo por padrão.

Se o aplicativo manipular SIGPIPE , suas tentativas de gravação retornarão um status de erro e, em seguida, dependerá do aplicativo se ele ignorar o erro, abortar ou fazer outra coisa. (Ignorar erros raramente é sábio.)

Se você quiser apenas a maneira mais fácil de impedir que o seu aplicativo morra e não queira redirecioná-lo para um arquivo, considere executá-lo em screen ou tmux ou use mosh em vez de ssh .