Deixar coisas a correr depois de fechar a ligação

Arranca-se um processo demorado por SSH, fecha-se a ligação, e no dia seguinte não há sinal dele. Acrescentar um & no fim não resolve — e perceber porquê explica todo o resto.

1. Porque é que o & não chega

O & manda o processo para segundo plano, mas ele continua a pertencer àquela sessão. Quando a ligação cai, o terminal desaparece e o núcleo avisa quem estava agarrado a ele com um sinal de desligar — que, por omissão, mata.

Ou seja: o & liberta a consola, não liberta o processo.

2. Ignorar o sinal: nohup

nohup ./tarefa-longa.sh > saida.log 2>&1 &

O nohup faz o processo ignorar aquele sinal. Sem a redireção, a saída vai para um ficheiro nohup.out na pasta atual, que cresce sem limite — mais vale escolher o destino.

Serve para o que é automático e não precisa de atenção. Tem uma limitação séria: não há forma de voltar lá. O processo corre, escreve para um ficheiro, e é tudo o que se consegue.

3. Para o que já está a correr: disown

# Já arrancou e agora é que me lembrei
Ctrl-Z
bg
disown -h %1

Suspende-se, manda-se para segundo plano, e tira-se da lista de tarefas da consola — que é o que a impede de o matar ao sair. Salva o trabalho de reiniciar um processo de três horas que já ia a meio.

4. O que se quer mesmo: tmux

Os anteriores desligam o processo do terminal. O tmux faz o contrário e melhor: mantém o terminal vivo do lado do servidor, sem depender da ligação.

tmux new -s migracao     # criar uma sessão com nome
# ... trabalhar normalmente ...
# Ctrl-b d                 para sair deixando tudo a correr

tmux ls                  # ver o que ficou aberto
tmux attach -t migracao  # voltar, do mesmo sítio ou de outro computador

A diferença prática é enorme: o processo continua interativo. Pode-se ver o que ele está a escrever, responder-lhe, interrompê-lo. E volta-se de outra máquina, o que salva quem arrancou uma migração no escritório e a quer acompanhar de casa.

Se a ligação cair sozinha, não se perde nada — a sessão fica lá, e o attach devolve tudo como estava.

5. O que nenhum destes faz

Nenhum sobrevive a um reinício da máquina. Nem o nohup, nem o tmux.

É a distinção que interessa reter: isto são ferramentas para a minha sessão, não para um serviço. Uma coisa que tem de estar sempre de pé não se arranca à mão dentro de um tmux — escreve-se uma unidade, e essa volta sozinha depois de um corte de energia. Está no artigo sobre o systemd.

O resumo

Para uma tarefa que corre uma vez e só precisa de deixar um registo, nohup com redireção. Para algo que se quer acompanhar, tmux. Para o que tem de estar sempre a correr, nem um nem outro — é caso para serviço.