1. Entendendo o systemd: units, serviços de sistema e serviços de usuário

1.1 Por que precisamos de um gerenciador de serviços?

Durante o desenvolvimento é natural iniciar uma aplicação pelo terminal:

python3 coletor.py
node server.js
./sensor-reader

Mas um equipamento industrial, gateway IoT ou servidor Linux precisa de algo mais confiável. O programa deve poder iniciar sem alguém abrir um terminal, sobreviver ao encerramento da sessão interativa, oferecer registros de execução e reagir a falhas.

Em muitas distribuições, o systemd exerce o papel de sistema de inicialização e gerenciador de serviços. Seu gerenciador de sistema normalmente é o processo de PID 1. Confira:

ps -p 1 -o pid,comm,args

O systemd não deve ser entendido como mero executor de scripts de boot: ele modela recursos, relacionamentos e estados de execução.

1.2 O que é uma Unit?

Uma Unit é uma entidade administrável pelo systemd. Exemplos:

Uma Unit de serviço não é necessariamente um processo individual. Um serviço pode possuir um processo principal, trabalhadores e processos auxiliares. Threads, por sua vez, são fluxos de execução dentro de processos e não Units independentes.

1.3 Serviço, processo e daemon

• Processo: instância executável identificada pelo kernel, geralmente com PID.
• Daemon: programa normalmente executado em segundo plano, de longa duração.
• Service Unit: definição declarativa de como iniciar, interromper e acompanhar determinado serviço.

Exemplo: nginx.service é a Unit; os processos nginx são executados e supervisionados segundo essa definição.

1.4 A estrutura de uma Unit

[Unit]
Description=Leitor de sensores

[Service]
ExecStart=/opt/sensor/bin/sensor

[Install]
WantedBy=multi-user.target

Pense nas três seções assim:

• [Unit]: identidade e relações com outras Units;
• [Service]: execução e supervisão;
• [Install]: como a Unit é associada a outras durante enable/disable.

1.5 Gerenciador de sistema versus gerenciador de usuário

O gerenciador de sistema é controlado por systemctl, frequentemente com sudo. Cada usuário também pode ter seu próprio gerenciador, controlado por systemctl --user.

Units fornecidas por pacotes normalmente ficam em /usr/lib/systemd/system/ (ou /lib/systemd/system/, conforme a distribuição). Evite editar arquivos de pacotes diretamente: use /etc/systemd/system/ e drop-ins de configuração.

Importante: um serviço de sistema não precisa executar como root. Por exemplo:

[Service]
User=coletor
Group=coletor
ExecStart=/opt/coletor/bin/coletor

1.6 start, enable e os estados

sudo systemctl start coletor.service       # inicia agora
sudo systemctl stop coletor.service        # interrompe agora
sudo systemctl restart coletor.service     # reinicia agora
sudo systemctl status coletor.service      # inspeciona
sudo systemctl enable coletor.service      # habilita ativação configurada
sudo systemctl enable --now coletor.service # habilita e inicia
sudo systemctl disable --now coletor.service

start não é enable: um serviço pode estar ativo mas desabilitado, ou habilitado mas inativo. enable normalmente cria links simbólicos com base em [Install]; não significa que o serviço passa imediatamente a rodar.

Estados habituais incluem active, inactive, activating, deactivating e failed. A identificação de uma Unit como loaded também é diferente de seu estado de execução.

Após modificar uma Unit:

sudo systemctl daemon-reload  # relê definições
sudo systemctl restart coletor.service # aplica alterações à execução

daemon-reload não reinicia automaticamente os serviços.

Ponto de aprendizagem

Conserve três distinções: Unit ≠ processo, sistema ≠ usuário e start ≠ enable. Com isso será mais fácil compreender as opções que veremos adiante.