5. Timers, logs, segurança e boas práticas

5.1 O que é um timer do systemd?

Uma Unit .timer permite ativar outra Unit com base no relógio de calendário ou no tempo transcorrido. Frequentemente, ela aciona um serviço Type=oneshot.

backup.timer → backup.service → script de backup → conclusão

O timer define quando; o serviço define como e com quais privilégios.

Essa separação é uma das principais vantagens do uso de timers no lugar de dispersar lógica de agendamento por scripts ou aplicações.

5.2 Criando um timer periódico

Vamos criar uma tarefa que registra uma mensagem no journal a cada execução, sem exigir acesso a arquivos sensíveis ou ao banco de dados.

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

[Unit]
Description=Geração de relatório de teste

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t relatorio "Relatório periódico executado"

Agora /etc/systemd/system/relatorio.timer:

[Unit]
Description=Dispara o relatório diariamente

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=relatorio.service

[Install]
WantedBy=timers.target

Em seguida:

sudo systemd-analyze verify /etc/systemd/system/relatorio.service
sudo systemd-analyze verify /etc/systemd/system/relatorio.timer
sudo systemctl daemon-reload
sudo systemctl enable --now relatorio.timer
systemctl list-timers --all

O timer será programado para disparar diariamente às 03:00 no fuso horário interpretado pelo gerenciador. Em um serviço de produção, verifique explicitamente a configuração de hora e timezone da máquina.

Persistent=true faz com que, em timers baseados em OnCalendar=, execuções perdidas por inatividade do timer possam disparar quando ele voltar a ser ativado. Não significa executar individualmente todas as ocorrências perdidas.

5.3 Testando o serviço sem esperar pelo timer

sudo systemctl start relatorio.service
sudo journalctl -t relatorio -n 20

Para visualizar os registros administrativos do serviço:

sudo journalctl -u relatorio.service -n 20

Isso é muito importante: depure primeiro a execução do serviço, depois o agendamento do timer.

5.4 OnCalendar versus OnBootSec e OnUnitActiveSec

Timers admitem diferentes relógios:

Exemplo de execução periódica baseada em tempo monotônico:

[Timer]
OnBootSec=1min
OnUnitActiveSec=10min
Unit=relatorio.service

Esse modelo é interessante para rotinas que devem ocorrer aproximadamente em intervalos após o boot, mas não em um horário fixo do calendário.

Validando expressões de calendário

systemd-analyze calendar 'Mon..Fri *-*-* 09:00:00'
systemd-analyze calendar --iterations=5 'daily'

A ferramenta mostra a interpretação e as próximas ocorrências previstas da expressão.

5.5 Precisão e aleatorização

Para reduzir a concentração de tarefas simultâneas em várias máquinas, um timer pode utilizar:

[Timer]
OnCalendar=hourly
RandomizedDelaySec=10min
AccuracySec=1min

RandomizedDelaySec= introduz atraso aleatório dentro da janela definida. AccuracySec= permite ao gerenciador ajustar/coalescer o disparo para eficiência. Não use timers comuns do systemd quando um requisito exige garantias rigorosas de tempo real em microssegundos ou determinismo de hard real-time.

5.6 Timers de usuário

O mesmo princípio funciona com o user manager. Exemplo ~/.config/systemd/user/resumo.service:

[Unit]
Description=Resumo pessoal periódico

[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t resumo-pessoal "Rotina pessoal executada"

Crie ~/.config/systemd/user/resumo.timer:

[Unit]
Description=Agenda do resumo pessoal

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

Habilite sem sudo:

systemctl --user daemon-reload
systemctl --user enable --now resumo.timer
systemctl --user list-timers --all
journalctl --user -u resumo.service

Se a tarefa deve funcionar sem login, consulte a Seção 3 sobre loginctl enable-linger.

5.7 Diagnóstico: comandos que vale memorizar

systemctl status coletor.service
systemctl cat coletor.service
systemctl show coletor.service
systemctl list-units --type=service
systemctl list-unit-files --type=service
systemctl list-timers --all
systemd-analyze critical-chain coletor.service
sudo journalctl -u coletor.service -b -n 100
sudo journalctl -u coletor.service -f

• systemctl cat: mostra a Unit e alterações por drop-ins.
• systemctl show: exibe propriedades efetivas em formato adequado à automação.
• critical-chain: ajuda a investigar caminhos críticos de inicialização, sem substituir análise completa de desempenho.
• journalctl: consulta registros; a retenção depende da configuração e da disponibilidade do journal.

Para serviços pessoais, use systemctl --user e normalmente journalctl --user.

5.8 Sobrescrevendo apenas uma configuração com drop-ins

Evite duplicar ou editar o arquivo instalado pelo pacote. Para uma Unit existente:

sudo systemctl edit coletor.service

Inclua apenas a seção e as opções alteradas, por exemplo:

[Service]
RestartSec=10s

Ao salvar, o systemctl edit organiza um drop-in e atualiza as definições conforme a ferramenta. Para verificar:

systemctl cat coletor.service

Reinicie o serviço se a mudança precisar ser aplicada ao processo já em execução:

sudo systemctl restart coletor.service

5.9 Endurecimento básico de segurança

Dependendo das necessidades da aplicação, considere:

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes

• NoNewPrivileges=yes: impede determinadas elevações futuras de privilégio.
• PrivateTmp=yes: fornece visões isoladas de diretórios temporários.
• ProtectSystem=strict: restringe montagens para tornar o sistema de arquivos predominantemente somente leitura no namespace do serviço.
• ProtectHome=yes: restringe acesso a diretórios pessoais.

Não aplique essas diretivas indiscriminadamente. Elas podem quebrar programas que precisam escrever em diretórios específicos, acessar dispositivos ou ler dados na home. Em serviços com escrita persistente, planeje diretórios com StateDirectory=, CacheDirectory=, LogsDirectory= ou autorizações apropriadas.

Uma Unit de serviço de sistema que armazena estado, por exemplo, pode usar:

[Service]
User=coletor
Group=coletor
StateDirectory=coletor
WorkingDirectory=/opt/coletor
ExecStart=/usr/bin/python3 /opt/coletor/coletor.py

A diretiva StateDirectory=coletor auxilia na criação/gestão de um diretório de estado em local gerenciado pelo sistema, normalmente sob /var/lib/ no contexto de serviço de sistema.

Avalie características de segurança com:

systemd-analyze security coletor.service

O resultado é uma avaliação heurística de isolamento, não um teste de invasão nem prova formal de segurança.

5.10 Uma checklist para colocar um serviço em produção

• O programa funciona corretamente fora do systemd?
• A Unit passa em systemd-analyze verify?
• O comando ExecStart= utiliza caminhos corretos?
• O serviço executa com usuário e permissões mínimos?
• A aplicação não depende de variáveis do shell interativo?
• Tratamento de SIGTERM e parada ordenada implementados?
• Estratégia de falha e reinicialização testada?
• Dependências distinguem ordenação de ativação?
• Logs podem ser consultados pelo journal?
• Credenciais não estão expostas em variáveis sem necessidade?
• Acesso a hardware e arquivos está documentado?
• Timers foram testados separadamente dos serviços?
• Se for oneshot, a tarefa é idempotente quando necessário?
• O comportamento após reboot foi testado?

5.11 Exercício integrador para IoT

Imagine um gateway industrial que realiza três tarefas:

1. preparar-hardware.service (Type=oneshot) aplica configurações iniciais necessárias ao dispositivo.
2. coletor.service (Type=exec) permanece ativo lendo sensores e processando mensagens; ele depende da preparação.
3. relatorio.timer ativa periodicamente relatorio.service (Type=oneshot) para gerar um resumo das leituras.

Essa composição demonstra como o systemd transforma executáveis isolados em uma infraestrutura operacional organizada.

Conclusão geral

Ao longo destas cinco seções, aprendemos a passar de um programa iniciado manualmente para uma arquitetura em que o Linux conhece seu ciclo de vida. Vimos por que systemctl start e enable são operações diferentes; quando utilizar serviços do sistema ou do usuário; como configurar execução, permissões e ambiente; por que oneshot é a escolha natural para tarefas finitas; e como timers permitem organizar tarefas periódicas.

O ponto central é separar lógica de negócio da política operacional. Em aplicações embarcadas, essa separação permite que equipes modifiquem firmware de gateway, código de aquisição, integração MQTT e rotinas de manutenção sem recriar todo o mecanismo de inicialização e monitoramento.

Para cargas com restrições severas de latência, vale lembrar que o systemd é sobretudo um gerenciador de serviços: ele não substitui um escalonador de tempo real, um RTOS ou a análise de prazos de um sistema hard real-time.

Referências e documentação

1. systemd.service — https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
2. systemd.unit — https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html
3. systemd.exec — https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
4. systemd.timer — https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
5. systemd.time — https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html
6. systemctl — https://www.freedesktop.org/software/systemd/man/latest/systemctl.html
7. journalctl — https://www.freedesktop.org/software/systemd/man/latest/journalctl.html
8. loginctl — https://www.freedesktop.org/software/systemd/man/latest/loginctl.html
9. systemd-analyze — https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html

Nota editorial: os exemplos são voltados ao aprendizado. Adapte caminhos, versões, permissões de dispositivos e requisitos de confiabilidade à sua distribuição e à aplicação real.