Cron vs systemd timers: como programar tarefas em um servidor Linux
Publicado em 2026-10-26 por frfrand
Diferenças entre cron e systemd timers para backups e automação
Você precisa gerar um resumo todas as noites ou limpar arquivos temporais uma vez por semana. Pode usar o cron, mas no Ubuntu moderno também existem os timers do systemd. Não é tanto uma briga: importa qual se integra melhor com logs, permissões e execução do seu serviço.
Te mostro onde está o problema, como verificá-lo sem chutar e o que faria em um aplicativo que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha específica.
O que significa cron vs systemd timers na prática
O cron usa expressões de horário e executa programas sob um usuário. Os timers do systemd ativam unidades de serviço e oferecem integração com o journal, dependências e políticas como Persistent=true para determinadas tarefas de calendário que foram perdidas enquanto o sistema estava desligado.
Uma esclarecimento antes de tocar no servidor: se o projeto já está em produção, salve o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas de uma vez dificulta encontrar a causa de um erro.
Comandos úteis para começar
# Ver timers activos
systemctl list-timers --all
# Ver una unidad concreta
systemctl status mi-tarea.timer
journalctl -u mi-tarea.service
# Cron del usuario actual
crontab -l
# Ejemplo de calendar en un timer
# OnCalendar=dailyOs caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por quê. As consultas de diagnóstico devem vir antes das modificações.
Passo a passo, com verificações
- Escreva primeiro um comando que funcione manualmente e tenha o código de saída correto.
- Se usar cron, defina caminhos absolutos: o ambiente não é igual ao shell interativo.
- Se usar systemd, separe
mi-tarea.servicedo timer e configure um usuário não privilegiado. - Teste o serviço manualmente antes de ativar seu timer.
- Verifique hora, fuso horário, logs, política de repetição e risco de execuções sobrepostas.
Depois de cada passo, verifique um resultado observável: um estado, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de ocultá-la com reinícios repetidos.
Exemplo real: uma aplicação que precisa ser mantida
Um backend de tours precisa gerar um relatório diário sem bloquear a API. Um serviço systemd separado com timer permite ver cada execução no journalctl e conceder apenas as credenciais necessárias.
Ao final, teste o caminho completo: entrar pelo domínio, chamar a API, gravar um dado de teste e verificar se a informação continua lá após uma reinicialização controlada. Um servidor que «arranca» nem sempre é uma aplicação que funciona.
Erros que vale a pena evitar
Um timer não converte automaticamente uma tarefa em idempotente. Se executar duas vezes um cobrança ou um e-mail em massa, você precisa proteger a lógica de negócio.
Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartidos ou capturas. Para usuários e serviços, use permissões mínimos e documente quem pode revogar o acesso.
Como o ArduMaker entra neste cenário
O ArduMaker permite administrar tarefas programadas em VPS. Registrar o comando, responsável, horário e resultado ajuda a saber se um relatório realmente foi executado.
O ArduMaker pode ajudá-lo a administrar os VPS, implantar repositórios e trabalhar com serviços, bancos de dados e domínios a partir da mesma plataforma. Não substitui o que acabamos de explicar sobre Linux: precisamente por isso convém entender o diagnóstico e ter uma forma de repeti-lo.
Quando convém automatizá-lo
Se a tarefa se repete, documente primeiro o procedimento manual e suas verificações. Depois considere um script ou uma tarefa programada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não sabe recuperar quando dá errado.
Perguntas frequentes
Posso testá-lo sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.
Como saber se ficou bem? Veja logs e uma operação funcional, não apenas se o comando terminou com código zero.
Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.
Referências
Em uma frase: primeiro entenda o erro, depois mude uma coisa concreta e comprove seu efeito. Essa disciplina economiza muitas horas de suporte.