Rotinas como backups automáticos, limpeza de logs ou qualquer script que precise rodar em um horário fixo tradicionalmente são resolvidas com cron. Mas em distribuições Linux modernas baseadas em systemd, existe uma alternativa nativa e mais robusta: os Systemd Timers.
Comparado ao cron, o Systemd Timer traz algumas vantagens práticas: integração direta com os logs do journalctl (facilitando o diagnóstico de falhas), suporte a Persistent=true (executando tarefas perdidas caso a máquina estivesse desligada no horário agendado), e configuração através de arquivos de unidade, seguindo o mesmo padrão usado por qualquer outro serviço do sistema.
Neste artigo, uso como exemplo um timer para rodar um script de backup automático diariamente.
Como funciona
Um Systemd Timer sempre trabalha em conjunto com um Service de mesmo nome: o .timer define quando a tarefa deve rodar, e o .service define o que deve ser executado. Os dois arquivos precisam ter exatamente o mesmo nome base para o systemd associá-los automaticamente.
Criando o timer
Crie um arquivo na pasta /lib/systemd/system/, escolhendo um nome para o timer — por exemplo, daily-db-backup.timer:
[Unit]
Description=Daily Docmost Backup Timer
[Timer]
OnCalendar=Mon..Sat 23:00
Persistent=true
[Install]
WantedBy=timers.target
Enter fullscreen mode Exit fullscreen mode
Explicando os principais campos:
-
OnCalendar=Mon..Sat 23:00: define quando a tarefa roda — neste exemplo, todos os dias de segunda a sábado, às 23h; -
Persistent=true: garante que, se a máquina estiver desligada no horário programado, a tarefa será executada assim que o sistema voltar a ligar (em vez de simplesmente perder a execução daquele dia).
Criando o service
Crie um segundo arquivo na mesma pasta, usando o mesmo nome base do timer — no exemplo, daily-db-backup.service:
[Unit]
Description=Daily Docmost Backup Service
[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/docmost-backup.sh
[Install]
WantedBy=default.target
Enter fullscreen mode Exit fullscreen mode
Onde:
-
Type=simple: indica que o processo principal é o próprio comando definido emExecStart(o tipo mais comum para scripts que rodam e terminam); -
User=root: define com qual usuário o script será executado — ajuste conforme a necessidade de permissões do seu script; -
ExecStart: caminho completo para o script que será executado quando o timer disparar.
O caminho do script (
/usr/local/bin/docmost-backup.sh, no exemplo) precisa existir e ter permissão de execução (chmod +x) antes de ativar o timer.
Ativando o timer
Depois de criar os dois arquivos, recarregue as configurações do systemd para que ele reconheça as novas unidades:
systemctl daemon-reload
Enter fullscreen mode Exit fullscreen mode
Ative e inicie o timer imediatamente:
systemctl enable --now daily-db-backup.timer
Enter fullscreen mode Exit fullscreen mode
⚠️ Repare que o nome usado no comando
enableprecisa ser exatamente igual ao nome do arquivo.timercriado — um erro comum é digitar um nome ligeiramente diferente (por exemplo,daily-docmost-backup.timerem vez dedaily-db-backup.timer), o que faz osystemdreclamar que a unidade não existe.
Verificando se está ativo
Para listar todos os timers agendados no sistema, incluindo o horário da próxima execução:
systemctl list-timers --all
Enter fullscreen mode Exit fullscreen mode
Esse comando mostra colunas como NEXT (próxima execução prevista) e LAST (última execução), úteis para confirmar que o agendamento está correto.
Monitorando a execução
Para acompanhar em tempo real se o serviço está rodando corretamente (ou para investigar falhas depois que o timer disparar):
journalctl -f --system
Enter fullscreen mode Exit fullscreen mode
Esse comando acompanha os logs do sistema em tempo real (-f, de follow) — é onde aparecem tanto a saída do script quanto qualquer erro de execução registrado pelo systemd.
Para consultar especificamente os logs do serviço criado (sem precisar filtrar manualmente entre todos os logs do sistema):
journalctl -u daily-db-backup.service
Enter fullscreen mode Exit fullscreen mode
Considerações finais
Systemd Timers são uma alternativa moderna e bem integrada ao cron tradicional, especialmente úteis quando você já depende do systemd para gerenciar outros serviços da máquina — manter tudo no mesmo padrão de configuração facilita tanto a manutenção quanto a investigação de problemas, já que os logs ficam centralizados no journalctl junto com o restante do sistema.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.