Como usar screen pra manter aplicação rodando após fechar SSH
Aprenda a usar o screen no Linux pra manter scripts e aplicações rodando depois de desconectar do SSH, com sessões persistentes e reanexáveis.
Toda vez que você abre uma conexão SSH e roda um script longo — uma compilação, um treinamento de modelo, um deploy, qualquer coisa que demore mais que alguns minutos — você fica refém da conexão. Quedas de rede, fechar a tampa do laptop, expirar timeout do roteador: qualquer um desses eventos derruba o SSH, e quando isso acontece, o processo que estava rodando em primeiro plano recebe um SIGHUP e morre junto.
O screen resolve esse problema desacoplando o processo do terminal interativo. Você cria uma sessão, roda o que precisa dentro dela, desanexa, fecha o SSH e vai embora. O processo continua rodando indefinidamente no servidor. Quando voltar — minutos ou dias depois — você reanexa a sessão e está exatamente onde parou, com a saída completa preservada.
Este tutorial mostra a instalação, os comandos essenciais e os atalhos que você vai usar 90% do tempo. Tempo estimado de execução: 10 a 15 minutos, incluindo prática.
Pré-requisitos
Você precisa de uma máquina Linux com acesso SSH funcionando (qualquer distribuição moderna serve: Ubuntu 22.04+, Debian 12+, Rocky 9, Alma 9). Acesso sudo é necessário apenas pra instalar o pacote — o uso do screen em si roda como usuário comum.
screen ~600 KB libc, libutempter 4.x ou superior Instalando o screen
Na maioria dos servidores de produção, o screen já vem instalado por padrão. Confira primeiro antes de instalar.
Verifique se o screen já está disponível:
which screen && screen --versionSe o comando retornar o caminho (/usr/bin/screen) e a versão, pule pra próxima seção. Caso retorne vazio ou “command not found”, siga pra instalação.
Instale em sistemas baseados em Debian/Ubuntu:
sudo apt update
sudo apt install -y screenEm distribuições da família Red Hat (Rocky Linux, AlmaLinux, CentOS Stream):
sudo dnf install -y screenConfirme a instalação:
screen --versionA saída esperada é algo como Screen version 4.09.00 (GNU) — qualquer versão 4.x serve. Versões 3.x ainda funcionam mas são raras hoje em dia.
Criando sua primeira sessão
A criação de sessões nomeadas é o padrão recomendado — facilita identificar e reanexar depois.
Crie uma sessão nomeada. Use um nome descritivo do que vai rodar dentro:
screen -S deployVocê vai notar uma tela “limpa” — parece um terminal normal, mas agora está dentro de uma sessão screen. Rode qualquer comando longo aqui. Pra exemplificar:
ping -c 1000 8.8.8.8Desanexe a sessão sem matar o processo. Esta é a operação mais importante do screen — o atalho Ctrl+a seguido de d:
Pressione Ctrl+a (segure Ctrl, aperte a, solte os dois), depois aperte d sozinho.
Você volta pro shell original. A mensagem [detached from 12345.deploy] confirma que a sessão continua rodando em background. Pode até fechar o SSH agora — o ping segue contando lá dentro.
Quase todos os comandos do screen começam com o prefixo Ctrl+a. Ele é chamado de “comando de controle” e funciona como um modo: você aperta Ctrl+a pra entrar no modo de comando, e a próxima tecla é a ação. Ctrl+a d = detach. Ctrl+a c = create new window. Ctrl+a ? = ajuda completa.
Listando e reanexando sessões
Depois de desanexar, você precisa saber quais sessões existem antes de voltar pra alguma.
Liste todas as suas sessões ativas:
screen -lsA saída mostra cada sessão com PID, nome e estado:
There are screens on:
12345.deploy (Detached)
12890.build (Detached)
2 Sockets in /run/screen/S-root.O número antes do ponto é o PID do daemon, o que vem depois é o nome que você deu. Estados comuns: (Detached) = solta esperando reanexar, (Attached) = alguém está conectado agora, (Dead) = morta mas com socket órfão (limpe com screen -wipe).
Reanexe a sessão. Use o nome ou o PID:
screen -r deployVocê vai cair exatamente onde parou — toda a saída do processo, posição do cursor, comandos no histórico. Tudo preservado. Se houver apenas uma sessão desanexada, screen -r sem argumentos resolve.
Forçar reanexação. Se você esquecer de desanexar e abrir uma nova conexão SSH tentando reanexar, vai dar erro There is no screen to be resumed matching .... Resolva forçando:
screen -dr deployA flag -d força o detach da sessão atual (mesmo que outro terminal esteja anexado) antes de reanexar pro seu. Use -D -RR pra “force detach, attach, create if not exists” — útil em scripts.
Comandos essenciais durante a sessão
Uma vez dentro da sessão, alguns atalhos extras vão facilitar o dia a dia.
| Atalho | Ação |
|---|---|
Ctrl+a d | Desanexa a sessão (deixa rodando em background) |
Ctrl+a c | Cria uma nova “janela” dentro da sessão |
Ctrl+a n | Próxima janela |
Ctrl+a p | Janela anterior |
Ctrl+a " | Lista todas as janelas pra selecionar |
Ctrl+a A | Renomeia a janela atual |
Ctrl+a [ | Entra em modo cópia/scroll (use setas, q pra sair) |
Ctrl+a k | Mata a janela atual (pede confirmação) |
Ctrl+a ? | Lista todos os atalhos disponíveis |
O conceito de “janelas dentro da sessão” é poderoso: dentro de uma única sessão deploy você pode ter uma janela rodando o build, outra com htop monitorando, outra com tail -f em logs. Tudo isolado, tudo persistente.
Por padrão, o screen guarda apenas 100 linhas de histórico no buffer. Se sua aplicação cospe muito log, considere redirecionar a saída pra um arquivo via comando 2>&1 | tee /tmp/saida.log — ou aumente o buffer permanentemente criando ~/.screenrc com defscrollback 10000.
Encerrando sessões corretamente
Quando a aplicação terminar, você precisa fechar a sessão pra ela não ficar como zumbi no screen -ls.
Reanexe a sessão e termine o processo normalmente (Ctrl+C ou comando de saída do app). Depois, encerre o shell da sessão:
exitIsso fecha o shell que o screen criou. A sessão é destruída e some do screen -ls. É a forma limpa.
Matar uma sessão à força sem reanexar (use quando travada):
screen -X -S deploy quitA flag -X envia um comando pra uma sessão específica, e quit termina ela. Útil quando o processo dentro está travado e você não quer reanexar pra debugar.
Limpe sessões mortas que ainda aparecem no screen -ls:
screen -wipeEsse comando remove todos os sockets órfãos de sessões cujo processo já morreu. Roda rápido e é seguro — não toca em sessões ativas ou desanexadas válidas.
Verificação
Pra confirmar que tudo funcionou, faça o teste do mundo real: desconecte do SSH com uma aplicação rodando e reconecte depois.
Crie uma sessão de teste com um contador simples:
screen -S teste
for i in $(seq 1 600); do echo "Tick $i — $(date +%T)"; sleep 1; doneDesanexe com Ctrl+a d e feche a conexão SSH completamente (exit ou feche o terminal).
Reconecte ao servidor via SSH e reanexe:
screen -r testeO contador deve estar muito além de onde você desanexou — prova de que continuou rodando sem você. Encerre com Ctrl+C e exit.
Resolução de problemas
”Cannot open your terminal ‘/dev/pts/0’”
Aparece quando você troca de usuário (sudo su - outro) e tenta usar screen. O novo usuário não tem permissão no pty original. Resolva rodando script /dev/null antes do screen — isso aloca um pty novo pro usuário corrente.
Sessão aparece “Attached” mas você não está em nenhuma
Conexão SSH anterior caiu sem desanexar limpo. O screen acha que ainda tem cliente. Resolva com screen -d -r nome — a flag -d força detach antes de anexar pra você.
Cores e formatação quebradas dentro do screen
A variável $TERM dentro do screen vira screen ou screen.xterm-256color, que algumas aplicações não reconhecem. Adicione export TERM=xterm-256color no seu .bashrc ou rode antes da aplicação.
Sessões screen rodando como root expõem um shell privilegiado persistente que sobrevive a desconexões. Se a sessão for sequestrada (compartilhamento via -x, ou acesso indevido ao usuário root), o atacante herda root direto. Prefira sempre rodar como usuário comum e elevar com sudo só quando necessário dentro da sessão.
Próximos passos
Agora que você domina o básico, alguns caminhos pra aprofundar:
- Crie um arquivo
~/.screenrccom configurações persistentes (status bar customizada, atalhos remapeados, scrollback grande). Exemplos completos noman screen. - Aprenda
tmuxcomo alternativa moderna — sintaxe similar, mas com splits gráficos nativos e configuração via arquivo bem mais limpa. - Pra processos que precisam sobreviver a reboots, monte um service unit do systemd com
Restart=always. screen e tmux não cobrem esse caso. - Estude
journalctl --userpra centralizar logs de aplicações longas rodando em background.
Se você está rodando workloads de longa duração — builds de horas, treinos de modelo, processamento de dados — uma VPS Hostini com SSD NVMe e CPU dedicada reduz o tempo de execução e dá previsibilidade, o que combina bem com o uso intensivo de screen pra manter tudo organizado em sessões.
Perguntas frequentes
Qual a diferença entre screen, tmux e nohup?
nohup só desacopla o processo do terminal e redireciona a saída pra um arquivo — você não consegue reanexar nem interagir depois. screen e tmux mantêm o processo numa sessão completa que você pode desanexar, reanexar e manipular. tmux é mais moderno (splits gráficos, configuração via arquivo), enquanto screen é mais simples e vem instalado por padrão em quase qualquer distro.
Se o servidor reiniciar, a sessão screen sobrevive?
Não. O screen mantém a sessão viva apenas enquanto o processo pai (o daemon) está rodando, e isso não sobrevive a um reboot. Pra resistir a reinícios, use systemd com um service unit, ou supervisord. screen é pra tarefas longas dentro de um mesmo uptime — compilações, treinamentos, scripts de manutenção.
Por que minha sessão screen aparece como (Dead) no screen -ls?
Significa que o processo dentro da sessão terminou mas o socket ficou órfão. Limpe com `screen -wipe`, que remove todas as sessões mortas. Se quiser capturar a saída antes de matar, use `screen -r nome` mesmo assim — em alguns casos ainda dá pra ler as últimas linhas no buffer.
Posso compartilhar uma sessão screen com outro usuário?
Sim, usando `screen -x nome_da_sessao` os dois conseguem ver e digitar simultaneamente. Útil pra pair-debugging remoto. Pra compartilhar com outro usuário Linux do mesmo servidor, o owner precisa rodar `screen -X multiuser on` e `screen -X acladd outro_user` dentro da sessão.
Como ver a saída completa da aplicação rodando dentro do screen?
Reanexe a sessão com `screen -r nome` e role pra cima usando Ctrl+a, seguido de Esc. Aí você usa as setas ou Page Up/Down pra navegar pelo buffer (cerca de 100 linhas por padrão). Pra aumentar o buffer, adicione `defscrollback 10000` no arquivo ~/.screenrc.
O screen está consumindo CPU mesmo sem nada dentro — é normal?
Não. Sessões screen idle consomem essencialmente zero CPU. Se você vê uso alto, provavelmente o processo dentro da sessão é que está consumindo (algum loop infinito, log spam, etc). Reanexe com `screen -r` e investigue. Se houver muitas sessões mortas acumuladas, rode `screen -wipe`.