Timers do Systemd vs. Cron: Escolhendo o Agendador Correto

Quando seu servidor Linux precisa executar um backup, limpeza, verificação de integridade ou relatório em um agendamento, você geralmente escolhe entre cron e timers do systemd. O Cron ainda é simples e portátil. Os timers do systemd se encaixam melhor quando a tarefa se comporta como um serviço gerenciado e precisa de logs, dependências ou controles de recursos.

A escolha certa depende da máquina que você executa, do comportamento de falha da tarefa e de quanta visibilidade operacional você precisa.

Entendendo os Jobs do Cron

cron é um agendador de tarefas baseado em tempo em sistemas operacionais do tipo Unix. Ele permite que os usuários agendem comandos ou scripts para serem executados periodicamente em horários, datas ou intervalos fixos. O daemon cron (crond) é executado em segundo plano e verifica os arquivos crontab em busca de tarefas agendadas.

Como o Cron Funciona

Cada usuário pode ter seu próprio arquivo crontab, gerenciado usando o comando crontab. As tarefas de todo o sistema são normalmente configuradas em /etc/crontab ou em arquivos dentro de /etc/cron.d/.

Uma entrada crontab segue um formato específico:

* * * * * comando_para_executar
│ │ │ │ │
│ │ │ │ └───── Dia da semana (0 - 6) (Domingo=0 ou 7)
│ │ │ └─────── Mês (1 - 12)
│ │ └───────── Dia do mês (1 - 31)
│ └─────────── Hora (0 - 23)
└───────────── Minuto (0 - 59)

Exemplo: Para executar um script de backup todos os dias às 2:00 AM:

0 2 * * * /usr/local/bin/backup.sh

Vantagens do Cron

• Ubíquo: Disponível em praticamente todos os sistemas do tipo Unix.
• Sintaxe Simples: O formato crontab é relativamente fácil de aprender para agendamento básico.
• Tarefas Específicas do Usuário: Fácil de configurar tarefas para usuários individuais.

Desvantagens do Cron

• Flexibilidade Limitada: Baseado principalmente em intervalos de tempo fixos. Lidar com dependências complexas ou agendamento orientado a eventos é difícil.
• Sem Gerenciamento de Dependências: Não é possível definir facilmente que uma tarefa só deve ser executada após outra tarefa ser concluída com sucesso.
• Sem Controle de Recursos: Oferece pouco ou nenhum controle sobre os recursos (CPU, memória) consumidos pelas tarefas agendadas.
• Registro e Monitoramento: Frequentemente depende de saída de e-mail, syslog ou redirecionamento explícito no comando.
• Integração com Arquivos de Unidade: Não integrado diretamente com os recursos de gerenciamento de serviços do systemd.

Entendendo os Timers do Systemd

Os timers do systemd são uma maneira mais avançada e flexível de agendar tarefas, aproveitando o poder dos arquivos de unidade do systemd. Em vez de um daemon separado, os timers do systemd são gerenciados como parte do próprio sistema de inicialização systemd.

Como os Timers do Systemd Funcionam

Os timers do systemd consistem em dois arquivos de unidade:

1. Unidade de Serviço (.service): Define a tarefa ou comando a ser executado.
2. Unidade de Timer (.timer): Define quando a unidade de serviço correspondente deve ser ativada.

Esses arquivos são normalmente colocados em /etc/systemd/system/ ou ~/.config/systemd/user/.

Exemplo: Agendando um script de limpeza para ser executado diariamente às 3:00 AM.

Primeiro, crie o arquivo de serviço (cleanup.service):

# /etc/systemd/system/cleanup.service

[Unit]
Description=Tarefa de limpeza diária

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup.sh

Em seguida, crie o arquivo de timer (cleanup.timer):

# /etc/systemd/system/cleanup.timer

[Unit]
Description=Executar tarefa de limpeza diariamente

[Timer]
# Executar 25 minutos após a inicialização e, em seguida, diariamente às 3 AM
OnBootSec=25min
OnCalendar=*-*-* 03:00:00
# Alternativa: Executar 24 horas após a última execução
# OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

Após criar esses arquivos, recarregue o systemd, habilite o timer para inicializações futuras e inicie-o agora:

sudo systemctl daemon-reload
sudo systemctl enable cleanup.timer
sudo systemctl start cleanup.timer

Você pode verificar o status do timer e quando ele será acionado novamente usando:

sudo systemctl status cleanup.timer

Diretivas Chave do Timer do systemd:

• OnCalendar=: Especifica um horário de evento de calendário (semelhante à sintaxe do cron, mas mais poderoso).
  • *-*-* 03:00:00: Diariamente às 3 AM.
  • Mon..Fri *-*-* 09:00:00: Dias úteis às 9 AM.
  • hourly: A cada hora.
  • daily: Uma vez por dia.
  • weekly: Uma vez por semana.
  • monthly: Uma vez por mês.
  • yearly: Uma vez por ano.
• OnBootSec=: Aciona um tempo especificado após a inicialização do sistema.
• OnUnitActiveSec=: Aciona um tempo especificado após a última ativação da unidade correspondente (serviço).
• OnUnitInactiveSec=: Aciona um tempo especificado após a unidade correspondente (serviço) se tornar inativa.
• AccuracySec=: Quão preciso o timer precisa ser. Valores mais baixos podem consumir mais energia.
• Persistent=: Para timers de calendário, true diz ao systemd para recuperar o atraso quando uma execução agendada foi perdida enquanto o timer estava inativo, como quando a máquina foi desligada.

Vantagens dos Timers do Systemd

• Integração com systemd: Integra-se perfeitamente com o gerenciamento de serviços, registro (journalctl), controle de recursos e gerenciamento de dependências do systemd.
• Flexibilidade: Suporta várias opções de agendamento além de intervalos fixos, incluindo eventos de calendário, tempos relativos após a inicialização e tempos relativos após a ativação anterior.
• Gerenciamento de Dependências: Pode definir dependências em outras unidades do systemd (por exemplo, disponibilidade de rede).
• Controle de Recursos: Pode aproveitar os cgroups do systemd para limitar recursos (CPU, memória).
• Registro: Integrado com o journald para registro abrangente e centralizado.
• Tratamento de Erros: Pode usar o comportamento da unidade de serviço, como Restart=, OnFailure= e ordenação de dependências onde esses padrões se encaixam na tarefa.
• Consciência de Estado: Pode rastrear quando uma tarefa deveria ser executada e executá-la na inicialização do sistema se Persistent=true estiver definido.

Desvantagens dos Timers do Systemd

• Curva de Aprendizado Mais Íngreme: A sintaxe e os conceitos do arquivo de unidade do systemd podem ser mais complexos do que o cron para iniciantes.
• Dependência do Systemd: Requer um sistema executando systemd (a maioria das distribuições Linux modernas o faz).

Timers do Systemd vs. Cron: Principais Diferenças Resumidas

Recurso	Jobs Cron	Timers do Systemd
Gerenciamento	Comando crontab, arquivos do sistema	Comando systemctl, arquivos de unidade
Agendamento	Minuto, hora, dia, mês, dia da semana fixos	Eventos de calendário, tempos relativos, baseado em inicialização
Integração	Daemon independente	Integrado com systemd
Registro	E-mail, redirecionamento de script	journald
Dependências	Nenhuma	Dependências de unidade do systemd
Controle de Recursos	Nenhum	cgroups do systemd
Tratamento de Erros	Básico	Tratamento de falha da unidade de serviço
Rastreamento de Estado	Limitado	Opção Persistent=
Complexidade	Mais simples para tarefas básicas	Mais poderoso, curva de aprendizado mais íngreme

Quando Escolher Cada Agendador

Escolha o Cron Quando:

• Você está em um sistema muito antigo ou mínimo que não usa systemd.
• Você precisa agendar uma tarefa muito simples e única com um agendamento fixo e recorrente, e prioriza a simplicidade sobre recursos avançados.
• Você precisa de um agendamento rápido para um comando que já lida com seus próprios logs e erros.

Escolha os Timers do Systemd Quando:

• Você está em uma distribuição Linux moderna que usa systemd.
• Você precisa de mais controle sobre quando uma tarefa é executada (por exemplo, relativo à inicialização, relativo à última execução, após a rede estar ativa).
• Você requer melhor registro, monitoramento e tratamento de erros.
• Você deseja gerenciar a execução de tarefas com os poderosos recursos de gerenciamento de serviços do systemd, incluindo controle de recursos e gerenciamento de dependências.
• Você já está gerenciando outros serviços com systemd e deseja uma abordagem consistente para agendamento.
• Suas tarefas têm dependências de outros serviços ou eventos do sistema.

Regra Prática

Use cron quando a tarefa for um comando curto e óbvio e a portabilidade for importante. Use um timer do systemd quando a tarefa fizer parte de um serviço, precisar de logs do journalctl, deve esperar pela rede ou se beneficiar de limites de recursos e ordenação de dependências.

Um backup noturno é um bom exemplo. Em um pequeno servidor legado, 0 2 * * * /usr/local/bin/backup.sh pode ser suficiente. Em um host de produção baseado em systemd, um backup.service mais backup.timer fornece status mais claro, logs, recuperação de inicialização com Persistent=true e um caminho mais limpo para adicionar dependências posteriormente.