Há algumas coisas para entender aqui:
-
nohup
não necessariamente evita que o programa perca a conexão. O que ele faz é mascarar o sinalHUP
, que é o que o SO irá enviar (na verdade, o shell de controle) quando você fizer logoff. Se o seu programa ainda tiver descritores de arquivos conectados ao terminal, ele será parado e possivelmente será cancelado. Para evitar que isso aconteça, nohup normalmente redireciona stdout e stderr paranohup.out
e fecha stdin. Mas se o seu programa pode tentar abrir descritores de arquivos para o terminal de qualquer maneira. -
O shell não controla "jobs" em invocações / sessões. Não há como anexar novamente um trabalho a um shell que foi encerrado. Existem vários problemas:
-
Use um emulador de terminal, como
screen
outmux
, que pode ser reconectado a um terminal diferente. Aqui, você não precisa executar o seu trabalho em segundo plano; basta executá-lo em primeiro plano e desanexar (Ctrl-A d
withscreen
). -
Acompanhe o PID do trabalho que foi iniciado. Você pode obter essas informações com o comando
jobs -l
depois de iniciado. Quando você deseja que o novo shell aguarde o trabalho e conhece o pid do trabalho, você pode emitir o comando:wait <pid>
-
Mas a saída ainda será enviada para nohup.out
, e seu único indício é que você verá um prompt de comando novamente.