Aprenda a gerenciar serviços com systemd: iniciar, parar, ativar no boot, ver erros no journal, criar overrides e um serviço para sua aplicação.

Para que serve

No Debian, no Ubuntu e no Proxmox VE, praticamente tudo o que roda em segundo plano (SSH, Nginx, banco de dados, a interface web do Proxmox) é um serviço do systemd. Saber controlá-los é a base para reiniciar uma aplicação, descobrir por que ela não sobe e garantir que ela volte sozinha depois de um reinício ou de uma falha. A seguir, veja como gerenciar serviços com systemd no dia a dia.

Pré-requisitos

  • Acesso root ou sudo.
  • O nome do serviço. Se não souber, procure com systemctl list-units --type=service | grep -i parte-do-nome.

Passo a passo para gerenciar serviços com systemd

1. Ver o estado de um serviço

systemctl status nginx

Os pontos principais da saída:

  • Loaded: onde está o arquivo da unidade e se ela está enabled (sobe no boot) ou disabled.
  • Active: active (running) está ok; failed indica que caiu ou não subiu.
  • As últimas linhas de log, que geralmente já mostram o erro.

2. Comandos do dia a dia

ComandoO que faz
systemctl start nomeInicia agora
systemctl stop nomePara agora
systemctl restart nomePara e inicia (derruba conexões)
systemctl reload nomeRelê a configuração sem derrubar (quando o serviço suporta)
systemctl enable --now nomeAtiva no boot e já inicia
systemctl disable --now nomeDesativa no boot e para
systemctl mask nomeImpede o serviço de ser iniciado por qualquer meio (desfaz com unmask)
systemctl --failedLista tudo o que falhou
systemctl list-unit-files --state=enabledLista o que sobe no boot
Cuidado ao mexer em serviços de acesso remoto. Parar ou reiniciar ssh, networking, systemd-networkd, o firewall ou, no Proxmox, pveproxy pode cortar sua sessão. Antes de reiniciar o SSH, valide a configuração com sshd -t. Se perder o acesso, entre pelo console IPMI/iLO.

3. Descobrir por que um serviço falhou

journalctl -u nome -n 100 --no-pager
journalctl -u nome -b          # somente desde o último boot
journalctl -u nome -f          # acompanhar em tempo real

Muitos serviços têm um comando para testar a configuração antes de reiniciar: nginx -t, apachectl configtest, sshd -t, named-checkconf. Use sempre que alterar um arquivo de configuração.

4. Ajustar um serviço sem editar o arquivo original

Os arquivos em /usr/lib/systemd/system/ pertencem aos pacotes e são substituídos nas atualizações. Para alterar algo, crie um override:

systemctl edit nginx

Abre-se um editor; escreva apenas o que quer mudar. Exemplo para reiniciar automaticamente em caso de falha e aumentar o limite de arquivos abertos:

[Service]
Restart=on-failure
RestartSec=5s
LimitNOFILE=65535

Ao salvar, o systemd grava em /etc/systemd/system/nginx.service.d/override.conf e recarrega sozinho. Aplique com systemctl restart nginx. Para ver a configuração final (original mais overrides): systemctl cat nginx.

5. Criar um serviço para a sua aplicação

Para rodar uma aplicação própria (Node.js, Python, Java, um binário Go) de forma permanente, crie /etc/systemd/system/minhaapp.service:

[Unit]
Description=Minha aplicação
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minhaapp
Group=minhaapp
WorkingDirectory=/opt/minhaapp
EnvironmentFile=-/etc/minhaapp.env
ExecStart=/opt/minhaapp/bin/servidor --porta 8080
Restart=on-failure
RestartSec=5s
NoNewPrivileges=true
ProtectSystem=full
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Crie o usuário de serviço sem login e ative:

useradd --system --home /opt/minhaapp --shell /usr/sbin/nologin minhaapp
systemctl daemon-reload
systemctl enable --now minhaapp

Pontos importantes: a aplicação deve rodar em primeiro plano (sem se "daemonizar"); não use nohup nem & no ExecStart; e evite rodar como root. Senhas e tokens vão no EnvironmentFile com permissão 600. Para definir as permissões da conta de serviço, veja também o artigo «Privilégio mínimo: como criar contas de serviço e permissões seguras no Linux, Proxmox e Windows».

Como saber se funcionou

  • systemctl is-active minhaapp responde active e systemctl is-enabled minhaapp responde enabled.
  • ss -tlnp | grep 8080 mostra a porta aberta pelo processo.
  • Teste o reinício automático: systemctl kill minhaapp e, alguns segundos depois, systemctl status minhaapp deve mostrar o serviço rodando de novo.

Problemas comuns

  • Unit nome.service not found: nome errado ou faltou systemctl daemon-reload após criar o arquivo.
  • status=203/EXEC: o caminho do ExecStart não existe, não é executável ou o script não tem a linha #!.
  • status=217/USER: o usuário definido em User= não existe.
  • start request repeated too quickly: o serviço caiu várias vezes seguidas e o systemd desistiu. Corrija a causa no log e rode systemctl reset-failed nome antes de iniciar de novo.
  • Serviço sobe antes da rede: use After=network-online.target e Wants=network-online.target, como no exemplo.

Perguntas frequentes

Qual a diferença entre systemctl restart e reload?

O restart para e inicia o serviço, derrubando as conexões abertas. O reload só pede ao serviço que releia a configuração, sem interromper o atendimento, e funciona apenas nos serviços que suportam isso.

Como fazer um serviço iniciar automaticamente no boot?

Use systemctl enable --now nome. Confira com systemctl is-enabled nome, que deve responder enabled.

Como ver por que um serviço não inicia?

Rode systemctl status nome e depois journalctl -u nome -n 100 --no-pager. O erro costuma aparecer nas últimas linhas.

Qual a diferença entre disable e mask?

O disable só tira o serviço do boot; ele ainda pode ser iniciado manualmente ou por outro serviço. O mask impede qualquer início até você rodar systemctl unmask.

Leitura complementar

Precisa de ajuda?

Se um serviço essencial não sobe e isso impede o acesso ao servidor, abra um ticket com a saída de systemctl status e journalctl -u do serviço.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também