MODULO 4.3

⚙️ Systemd: Servicos que Nunca Param

Voce subiu sua aplicacao no servidor, mas o que acontece quando o servidor reinicia? Ou quando o programa trava? O systemd e o gerente que mantem seus servicos de pe 24 horas por dia, 7 dias por semana. Aqui voce aprende a transformar qualquer programa em um servico que nunca para.

6
Topicos
45
Minutos
Basico
Nivel
Pratico
Tipo
1

O Que e o Systemd

O systemd e o gerente de plantao do seu servidor Linux. Ele e o primeiro programa que liga quando a maquina inicia e fica responsavel por subir, vigiar e religar todos os outros servicos. Sem ele, voce teria que abrir o terminal e iniciar seu programa na mao toda vez que o servidor reiniciasse. Com ele, voce define uma vez como o servico deve rodar e o systemd cuida do resto, dia e noite.

systemd (PID 1) gerente de plantao 24/7 meuapp.service active (running) api.service travou → restart nginx.service active (running)

🧠 Analogia: O Gerente de Plantao

Imagine um predio comercial com um gerente que nunca dorme. A funcao dele e simples: manter as luzes acesas, os elevadores funcionando e a recepcao aberta. Se um equipamento desliga, ele liga de novo na hora. Se acaba a energia e volta, ele reabre tudo automaticamente. Esse gerente e o systemd, e os equipamentos sao os seus servicos.

  • •Liga os servicos: quando o servidor inicia
  • •Vigia os servicos: verifica se continuam de pe
  • •Religa os servicos: se algum travar ou cair
  • •Anota tudo: guarda os registros (logs) do que aconteceu

💡 Vocabulario: unit, service e PID 1

No mundo do systemd, cada coisa que ele gerencia e uma unit (unidade). O tipo mais comum de unit e o service (servico), que e um programa que roda em segundo plano. O systemd em si e o PID 1: o processo de numero 1, o pai de todos os outros processos da maquina. Quando voce ouvir "criar um service", entenda "ensinar o gerente a cuidar do seu programa".

2

Criando Seu Primeiro Service File

Para o systemd cuidar do seu programa, voce precisa escrever um arquivo de servico. E um arquivo de texto simples que termina em .service e fica na pasta /etc/systemd/system/. Nele voce explica para o gerente o que rodar, como rodar e quando rodar.

Crie o arquivo com o nano

# Precisa de sudo: a pasta e do sistema

$ sudo nano /etc/systemd/system/meuapp.service

O nome antes do .service e como voce vai chamar o servico depois. Escolha algo curto e sem espacos.

📝 As tres secoes: Unit, Service e Install

Todo service file tem tres blocos. Cada um responde uma pergunta diferente:

[Unit]

Description=Minha aplicacao Node

After=network.target

# ------------------------------

[Service]

ExecStart=/usr/bin/node /home/deploy/app/server.js

WorkingDirectory=/home/deploy/app

User=deploy

Restart=always

# ------------------------------

[Install]

WantedBy=multi-user.target

[Unit]

"Quem sou eu?" Descricao do servico e de quem ele depende para iniciar.

[Service]

"Como me executar?" O comando que liga o programa, a pasta, o usuario e a politica de restart.

[Install]

"Quando me ligar no boot?" Em que momento da inicializacao o servico entra.

⚠️ Erro Comum

Problema: "Coloquei so node server.js no ExecStart e deu erro."
Solucao: O systemd nao sabe onde fica o node. Sempre use o caminho completo do executavel. Descubra com which node (vai mostrar algo como /usr/bin/node) e use esse caminho inteiro no ExecStart.

3

Controlando o Servico: start, stop, restart, enable

Depois de escrever o arquivo, voce conversa com o systemd usando o comando systemctl. Pense nele como o controle remoto do gerente: liga, desliga, reinicia e agenda os servicos para o boot.

Sempre que mudar o arquivo: recarregue

Toda vez que voce cria ou edita um .service, o systemd precisa reler os arquivos:

$ sudo systemctl daemon-reload

# sem saida = deu certo

Ligar, parar e reiniciar

# Iniciar o servico agora

$ sudo systemctl start meuapp

# Parar o servico

$ sudo systemctl stop meuapp

# Reiniciar (parar e ligar de novo)

$ sudo systemctl restart meuapp

# Ver o estado atual

$ sudo systemctl status meuapp

● meuapp.service - Minha aplicacao Node

Loaded: loaded (/etc/systemd/system/meuapp.service)

Active: active (running) since Tue 2026-06-17 12:30:01

Main PID: 4821 (node)

Note: voce nao precisa digitar o .service no fim. O systemd entende meuapp sozinho.

👁 enable: a diferenca que conta

O start liga o servico agora, mas se o servidor reiniciar ele nao volta. O enable marca o servico para iniciar sozinho no boot. Quase sempre voce quer os dois.

# Iniciar no boot (mas nao agora)

$ sudo systemctl enable meuapp

# Iniciar agora E no boot (o mais usado)

$ sudo systemctl enable --now meuapp

# Desfazer: nao iniciar mais no boot

$ sudo systemctl disable meuapp

✓ O que FAZER

  • ✓Rodar daemon-reload apos editar o arquivo
  • ✓Conferir com status se ficou ativo
  • ✓Usar enable --now para producao

✗ O que NAO fazer

  • ✗Esquecer o enable e perder o servico no reboot
  • ✗Confundir start (agora) com enable (boot)
  • ✗Editar o arquivo e nao recarregar o daemon
4

Lendo os Logs com journalctl

Quando um servico falha, a primeira pergunta e: "o que ele disse antes de cair?". O systemd guarda tudo que cada servico imprime na tela em um diario central. Voce le esse diario com o comando journalctl. E o seu detetive de problemas.

🧠 Analogia: O Diario de Bordo

Pense no journalctl como o diario de bordo de um navio. Tudo que acontece fica anotado com data e hora: quando o servico subiu, quando reiniciou, qual erro apareceu. Quando algo da errado, voce abre o diario na pagina certa e descobre o que aconteceu, sem adivinhar.

Os filtros essenciais: -u, -f e --since

# -u = filtra por um servico (unit)

$ journalctl -u meuapp

jun 17 12:30:01 srv node[4821]: Servidor na porta 3000

jun 17 12:34:18 srv node[4821]: GET /api/users 200

# -f = acompanha ao vivo (follow), como assistir

$ journalctl -u meuapp -f

(novas linhas aparecem em tempo real... Ctrl+C para sair)

# --since = a partir de quando

$ journalctl -u meuapp --since "hoje"

$ journalctl -u meuapp --since "10 min ago"

# Combinando: so erros das ultimas 30 linhas

$ journalctl -u meuapp -n 30 --no-pager

💡 Dica: o trio que resolve 90% dos casos

Quando seu servico nao sobe, rode systemctl status meuapp para ver o resumo, depois journalctl -u meuapp -n 50 para ler as ultimas linhas de erro. Se quiser ver acontecendo na hora, deixe journalctl -u meuapp -f aberto e reinicie o servico em outra aba.

⚠️ Erro Comum

Problema: "O journalctl abre uma tela esquisita e nao sai."
Solucao: Por padrao ele abre no paginador. Use as setas para rolar, q para sair, ou adicione --no-pager para jogar tudo direto na tela. Para ir ao fim do log, aperte Shift+G.

5

Dependencias: After e Requires

Servicos raramente vivem sozinhos. Sua aplicacao talvez precise do banco de dados ligado antes de subir, ou da rede pronta. O systemd deixa voce declarar essa ordem com duas chaves: After (ordem) e Requires (obrigatoriedade).

1

network.target sobe

A rede fica pronta. Quase todo servico de internet espera por isso primeiro.

2

postgresql.service sobe

O banco de dados liga. Sua aplicacao precisa dele de pe para se conectar.

3

meuapp.service sobe por ultimo

So agora, com rede e banco prontos, sua aplicacao inicia sem erros de conexao.

Declarando a ordem no service file

[Unit]

Description=Minha aplicacao

# Sobe DEPOIS da rede e do banco

After=network.target postgresql.service

# O banco e OBRIGATORIO: se ele cair, eu caio junto

Requires=postgresql.service

After=

Define so a ordem: "me ligue depois deste". Nao obriga o outro a existir. Se o servico citado nao subir, o seu sobe mesmo assim.

Use para: garantir que a rede esteja pronta antes.

Requires=

Cria dependencia forte: "eu nao funciono sem ele". Se o servico exigido falhar, o seu tambem para. Costuma vir junto com After.

Use para: o banco de dados sem o qual o app nao roda.

💡 Dica: After e Requires sao independentes

Requires garante que o outro servico seja iniciado junto, mas nao garante a ordem. Para ter ordem E obrigatoriedade, declare os dois: Requires=db.service mais After=db.service. Esse par e o jeito correto de dizer "preciso do banco, e ligado depois dele".

6

Restart Automatico: o Superpoder do Systemd

Aqui esta o motivo de usar systemd: ele religa seu servico sozinho quando ele cai. Travou por um bug? Acabou a memoria? O gerente percebe e sobe tudo de novo em segundos, sem voce precisar acordar de madrugada. Isso se configura com duas chaves: Restart e RestartSec.

No bloco [Service]

[Service]

ExecStart=/usr/bin/node /home/deploy/app/server.js

# Sempre religa, nao importa o motivo

Restart=always

# Espera 5 segundos antes de tentar de novo

RestartSec=5

Os valores mais usados de Restart

always Religa sempre, mesmo se o programa saiu sem erro. O mais comum para apps web.
on-failure Religa so quando o programa termina com erro (codigo diferente de zero).
no Nunca religa (e o padrao se voce nao definir nada). Evite em producao.

👁 O que voce vai ver no status apos um crash

● meuapp.service - Minha aplicacao Node

Active: active (running) since Tue 12:40:09

Main PID: 5102 (node)

# No journalctl, o systemd anota o religamento:

12:40:04 systemd: meuapp.service: Main process exited, code=killed

12:40:09 systemd: meuapp.service: Scheduled restart, attempt 1

12:40:09 systemd: Started Minha aplicacao Node.

⚠️ Erro Comum

Problema: "Meu app tem um bug que faz ele cair na hora, e o systemd fica religando em loop sem parar."
Solucao: Sem RestartSec, ele tenta religar instantaneamente e o systemd bloqueia por excesso de tentativas (start-limit). Coloque RestartSec=5 para dar um respiro entre as tentativas, e conserte o bug olhando o journalctl. Restart nao substitui corrigir o erro.

✓ O que FAZER

  • ✓Usar Restart=always em apps web
  • ✓Definir RestartSec=5 para evitar loop
  • ✓Olhar o log para entender por que caiu

✗ O que NAO fazer

  • ✗Deixar Restart=no em producao
  • ✗Usar o restart para mascarar bugs sem corrigir
  • ✗Esquecer daemon-reload apos mudar as chaves

📚 Resumo do Modulo

✓
Systemd e o gerente de plantao - mantem seus servicos de pe 24/7
✓
O service file tem [Unit], [Service] e [Install] - vive em /etc/systemd/system/
✓
systemctl start/stop/restart/enable - enable faz iniciar no boot
✓
journalctl -u, -f, --since - le os logs para descobrir o que aconteceu
✓
After/Requires e Restart=always - ordem entre servicos e religamento automatico

Proximo Modulo:

4.4 - Cron Jobs: Tarefas Agendadas (rodar comandos sozinho em horarios definidos)

← Voltar para Trilha Proximo Modulo →