Intermediário Fundamental Progresso 0%

Serviços com systemctl

start, stop, enable e unit files, operando serviços com systemd na prática.

01. Conceito

O que o systemd faz

Explicação

O systemd é o gerenciador de init e serviços da maioria das distribuições Linux modernas. Ele é o processo PID 1 em muitos sistemas e decide a ordem em que serviços sobem, reiniciam, aguardam dependências e escrevem logs.

Na prática, systemctl é a interface operacional mais usada: você pergunta status, reinicia um serviço travado, habilita no boot e descobre rapidamente por que algo falhou.

Analogia

Pense no systemd como o coordenador de um prédio técnico. Cada elevador, bomba de água e porta automática é um serviço. O coordenador sabe o que deve ligar primeiro, o que depende de quê e quem precisa ser reiniciado quando algo falha.

Guarde isto
  • systemd coordena boot e serviços.
  • systemctl é o comando operacional do dia a dia.
  • Serviço que falha quase sempre deixa pista em status e log.
02. Comandos

Units, status e ciclo básico

Explicação

O systemd trabalha com units. O tipo mais comum é .service, mas existem outros: .socket, .timer, .mount, .target. Quando você fala "nginx", normalmente está lidando com nginx.service.

Comandos reais 
sudo systemctl status nginx
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx
sudo systemctl is-active nginx
Erros comuns

Reiniciar sem olhar o status: muita gente roda restart em loop e perde a causa raiz. O correto é: ver status, ler a mensagem de falha e só depois agir.

Confundir reload com restart: reload recarrega configuração sem matar o processo principal, quando o software suporta isso. restart derruba e sobe de novo.

03. Persistência

Enable, disable e o boot

Explicação

start sobe o serviço agora. enable faz o serviço subir automaticamente no próximo boot. São coisas diferentes.

Exemplo prático 
sudo systemctl start ssh
sudo systemctl enable ssh
sudo systemctl disable ssh
sudo systemctl is-enabled ssh
Mini troubleshooting
  • Se o serviço funciona agora, mas some após reboot, verifique is-enabled.
  • Se está enabled mas não sobe, olhe dependências e falhas no boot.
  • Para confirmar: systemctl list-unit-files --type=service | grep nome.
04. Configuração

Arquivos de unit e daemon-reload

Explicação

Services costumam ser definidos em arquivos como /etc/systemd/system/minha-app.service. Neles você declara ExecStart, usuário, dependências, restart policy e outros comportamentos.

Exemplo concreto 
[Unit]
Description=Minha API Node
After=network.target

[Service]
User=www-data
WorkingDirectory=/srv/minha-api
ExecStart=/usr/bin/node server.js
Restart=on-failure

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now minha-api
sudo systemctl status minha-api
Erro comum

Editou a unit e nada mudou? Faltou daemon-reload. Sem isso, o systemd continua usando a definição antiga em memória.

05. Diagnóstico

Quando o serviço não sobe

Fluxo real 
sudo systemctl status nginx
sudo journalctl -u nginx -n 50 --no-pager
sudo ss -tulpn | grep ':80'
sudo nginx -t
Raciocínio

Quase toda falha de serviço cai em uma destas categorias: porta já ocupada, arquivo de configuração inválido, permissão insuficiente, caminho errado em ExecStart ou dependência não disponível.

Checklist
  • status para a visão resumida.
  • journalctl -u para a evidência detalhada.
  • Teste a config com a ferramenta nativa sempre que existir.
  • Confirme porta, usuário e caminho de execução.

Flashcards

Quiz

Tópico 1 de 5