Como criar um serviço systemd para manter um app rodando

Transforme qualquer script ou app em um serviço gerenciado que inicia no boot, reinicia se cair e registra no journalctl. Escreva um arquivo unit, ative-o e verifique seu status — a forma padrão de rodar algo 24/7 no Linux.

Rodar um app com & ou nohup funciona bem até o servidor reiniciar, o processo cair ou você querer achar seus logs — aí tudo desmorona. systemd é a resposta padrão: inicia seu app no boot, reinicia-o se ele morre e captura seus logs. Transformar um script ou binário em um serviço gerenciado é um arquivo pequeno.

1. Escreva um arquivo unit

Crie /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network.target

[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/run.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Ajuste ExecStart, WorkingDirectory e User ao seu app. Restart=always é o que o mantém vivo.

2. Crie um usuário dedicado (recomendado)

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo chown -R myapp:myapp /opt/myapp

Rodar como usuário sem privilégios de root limita o dano se o app um dia for comprometido.

3. Ative-o e inicie-o

sudo systemctl daemon-reload
sudo systemctl enable --now myapp

enable faz iniciar no boot; --now inicia imediatamente.

4. Verifique status e logs

sudo systemctl status myapp
journalctl -u myapp -f       # acompanhar os logs ao vivo

Comandos do dia a dia

sudo systemctl restart myapp   # reiniciar após uma mudança
sudo systemctl stop myapp      # pará-lo
sudo systemctl disable myapp   # parar de iniciar no boot

Avisos honestos

Rode daemon-reload após editar um arquivo unit, ou o systemd usa a versão antiga.
Cuidado com loops de queda. Se o app falha instantaneamente, Restart=always tenta para sempre — RestartSec=5 espaça as tentativas; corrija o erro de raiz pelos logs.
Prefira um User= sem privilégios de root para que um app comprometido não seja dono do servidor inteiro.

Próximos passos

Um serviço systemd é como você mantém qualquer coisa rodando 24/7 — por exemplo um agente de IA que roda o tempo todo ou o relay por trás de um servidor RustDesk auto-hospedado. Se seu app for containerizado, o --restart unless-stopped do Docker cumpre o mesmo papel — veja como instalar o Docker.

Perguntas frequentes

Por que usar systemd em vez de só rodar o app em segundo plano?

Um processo em segundo plano (com & ou nohup) morre no reboot, não volta se cair e espalha seus logs. Um serviço systemd inicia automaticamente no boot, reinicia em caso de falha e envia sua saída para o journalctl. É a forma padrão e confiável de rodar algo de vida longa no Linux.

Onde ficam os arquivos unit?

Seus próprios serviços ficam em /etc/systemd/system/, um arquivo por serviço, nomeado algo.service. Após criar ou editar um, rode 'systemctl daemon-reload' para o systemd captar a mudança, e então ative-o e inicie-o.

O que 'Restart=always' faz, e há desvantagens?

Diz ao systemd para reiniciar o serviço sempre que ele sair, por qualquer motivo — a chave para manter algo rodando. A única armadilha é o loop de queda: se o app falha instantaneamente ao iniciar, o systemd fica reiniciando. Adicione 'RestartSec=5' para espaçar as tentativas, e veja os logs para corrigir o erro de fundo.

Como vejo os logs do serviço?

Use 'journalctl -u yourservice -f' para acompanhar a saída ao vivo, ou sem -f para ler o histórico. O systemd captura stdout e stderr automaticamente, então você não precisa ligar arquivos de log por conta própria.

O serviço deve rodar como root?

De preferência não. Crie um usuário dedicado sem privilégios de root e defina 'User=' no unit, para que um comprometimento do app não entregue a máquina inteira. Rode como root só quando o serviço realmente precisar.

Comentários

Nenhum comentário ainda. Seja o primeiro.