Para rodar um comando em segundo plano depois de sair do SSH, o mais simples é nohup ./import.sh > import.log 2>&1 & — isso cobre o caso em que você já sabe de antemão que o processo vai sobreviver à sessão. Mas existem outras cinco situações que esse comando não resolve: desde lembrar do nohup tarde demais até um processo que precisa sobreviver não só à queda do SSH, mas também a um reboot.
1. Já sei de antemão que o processo vai demorar
$ clai rode esse script de um jeito que sobreviva a uma queda de ssh, e grave a saída num arquivo→ nohup ./import.sh > import.log 2>&1 &O nohup intercepta o SIGHUP que o processo recebe quando o terminal fecha. O & manda para segundo plano. O redirecionamento não é opcional: sem ele, a saída vai parar no nohup.out no diretório atual, e depois você vai ficar procurando.
2. Já rodei e esqueci do nohup
$ clai desvincule o processo que eu já iniciei, esqueci do nohup→ Ctrl+Z; bg; disown -h %1Ctrl+Z suspende, bg retoma em segundo plano, disown -h tira o processo da lista de jobs do shell para que ele não receba SIGHUP. É a opção de resgate para quando o processo já está rodando há uma hora e matar não é opção.
3. Preciso desvincular completamente da sessão
$ clai rode esse comando numa sessão própria, totalmente desvinculada do terminal→ setsid --fork ./import.sh > import.log 2>&1setsid cria uma nova sessão e grupo de processos, então o processo nunca recebe sinais do terminal. Mais radical que o nohup: de cara ele não tem terminal de controle para perder.
4. Preciso voltar depois para dar uma olhada
$ clai rode isso em segundo plano para eu poder reconectar depois e ver como está→ tmux new -d -s import './import.sh'-d cria a sessão desanexada. Depois, tmux attach -t import te leva direto de volta ao terminal vivo onde o processo está rodando. É a única opção da lista em que dá para interagir, não só olhar.
5. Quero que o systemd cuide disso
$ clai rode isso como um serviço systemd temporário, com log e status→ systemd-run --user --unit=import ./import.shRunning as unit: import.service; invocation ID: 74282bc256f144cdb323c19fc09452afVocê tem o log via journalctl --user -u import, o status via systemctl --user status import, e reinício automático se quiser. A melhor opção para algo que precisa sobreviver tanto à sua sessão quanto a um reboot.
6. Verificar se o processo está mesmo desvinculado
$ clai verifique se esse processo está mesmo desvinculado do terminal→ ps -o pid,ppid,sid,tty,comm -p 12345Se a coluna TTY mostrar ?, não há terminal de controle e uma queda de conexão não afeta o processo. Se mostrar pts/0, ele ainda está preso à sua sessão e morre junto com ela.
Pegadinhas
nohupsem redirecionamento escreve em nohup.out. O arquivo é criado no diretório atual, ou no diretório home se ali não der para escrever. Defina o caminho explicitamente.disownnão protege contra um SIGHUP que já foi enviado. Ele só tira o job do controle do shell. Se você já fechou o terminal, é tarde demais.- tmux e screen não sobrevivem a um reboot. Para algo que precisa sobreviver a um reinício, é preciso uma unit do systemd, não um multiplexador.
Perguntas relacionadas
nohup ou tmux? nohup é "rodou e esqueceu", saída para um arquivo. tmux é para quando você precisa voltar a um processo vivo e digitar algo nele.
Por que o processo morreu mesmo assim depois que eu saí? Ou não foi SIGHUP — ele morreu junto com o pai — ou ele mesmo travou com erro. Olhe o log, se você redirecionou para um.
Como vejo a saída de um processo em segundo plano que já está rodando? Se a saída vai para um arquivo, use tail -f. Se não vai para lugar nenhum, dá para espiar com strace -p PID -e write ou pelos descritores em /proc/PID/fd.
Veja também
O CliAI não vai lembrar de colocar nohup por você, mas escolhe a ferramenta certa para a situação antes de você rodar qualquer coisa. Instale em uma linha.