Agendamento de Tarefas: cron, at e Timers do systemd

2026-05-30 Tempo de leitura: Cerca de 15 min Dificuldade: Intermediário

O Que Você Vai Conquistar

• Ler e escrever a sintaxe do crontab (cinco campos)
• Explicar a diferença entre um crontab de usuário e um crontab de sistema (/etc/crontab, /etc/cron.d)
• Gerenciar tarefas únicas com at / atq / atrm
• Decidir quando usar anacron e systemd timer
• Entender o controle de execução com cron.allow / cron.deny
• Evitar armadilhas frequentes no exame como o "problema do PATH no cron"

Este é o núcleo do objetivo 107.2 do LPIC-1 "Automatizar tarefas de administração do sistema por agendamento de tarefas". É a técnica para executar trabalhos rotineiros, como backups regulares e rotação de logs, automaticamente sem intervenção humana.

Qual Agendador Você Deve Usar?

Para execuções repetidas escolha cron, para uma única execução escolha at, para execuções periódicas em uma máquina que nem sempre está ligada escolha anacron, e para controle avançado em um ambiente systemd escolha systemd timer. Esse é o ponto de partida para a decisão.

cron pula uma tarefa se a máquina não está ligada no horário agendado. Em contraste, anacron julga por "dias decorridos desde a última execução", portanto não perde execuções mesmo em ambientes como laptops que ficam desligados por períodos.

A Sintaxe do crontab

Cada linha do crontab consiste em seis elementos: "minuto hora dia mês dia-da-semana comando". Os cinco primeiros são campos de tempo, e do sexto em diante é o comando a executar.

# ┌───────────── minuto (0 - 59)
# │ ┌───────────── hora (0 - 23)
# │ │ ┌───────────── dia do mes (1 - 31)
# │ │ │ ┌───────────── mes (1 - 12)
# │ │ │ │ ┌───────────── dia da semana (0 - 7, 0 e 7 sao domingo)
# │ │ │ │ │
# * * * * * comando a executar

Os caracteres especiais utilizáveis em cada campo são os seguintes.

Vamos ler alguns exemplos concretos.

*/15 * * * *   /usr/local/bin/check.sh      a cada 15 minutos
0 3 * * *      /usr/local/bin/backup.sh     diariamente as 3:00
0 9 * * 1-5    /usr/local/bin/report.sh     dias uteis (seg-sex) as 9:00
0 0 1 * *      /usr/local/bin/monthly.sh    1o dia de cada mes as 0:00

No cron estilo Vixie você também pode usar apelidos como @reboot, @daily, @hourly, @weekly, @monthly, @yearly (@annually) e @midnight. @reboot executa uma vez quando o daemon cron inicia.

Passos

Passo 1: Editar o crontab do usuário

crontab -e

crontab: installing new crontab

crontab -e abre um editor (definido por $EDITOR / $VISUAL) e edita o crontab do usuário atual. Ao salvar, ele é armazenado em /var/spool/cron/ (ou crontabs/ dependendo da distribuição) e o daemon cron o detecta automaticamente. Adicionar a seguinte linha executa o backup diariamente às 3:00.

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

Passo 2: Listar e remover entradas

crontab -l
crontab -r

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

crontab -l mostra as entradas registradas e crontab -r remove o crontab inteiro. Como -r deleta sem confirmação, é mais seguro manter uma cópia com -l primeiro. Como root você pode operar o crontab de outro usuário com crontab -u user -e / -u user -l.

Passo 3: Usar o crontab do sistema

cat /etc/crontab
ls /etc/cron.d/

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly

/etc/crontab e os arquivos em /etc/cron.d/ são o crontab do sistema. Diferente do crontab de usuário, eles inserem um campo "executar como usuário" entre os campos de tempo e o comando (um layout de seis campos). Essa diferença é frequente no exame. Colocar scripts em /etc/cron.{hourly,daily,weekly,monthly} os executa em cada intervalo via run-parts.

Passo 4: Executar uma vez com at

at 22:00 tomorrow
atq
atrm 2

warning: commands will be executed using /bin/sh
at> /usr/local/bin/deploy.sh
at> <EOT>
job 2 at Sat May 31 22:00:00 2026
2	Sat May 31 22:00:00 2026 a user

at executa uma tarefa uma vez em um horário especificado. Digite o comando no prompt e confirme com Ctrl+D (<EOT>). Verifique a fila com atq (= at -l) e delete a tarefa número 2 com atrm 2 (= at -d 2). O horário pode ser dado de forma flexível, como 10:00, now + 1 hour, midnight ou teatime (16:00). batch difere do at em que executa a tarefa quando a carga do sistema diminui.

Passo 5: Controlar quem pode agendar tarefas

cat /etc/cron.allow
cat /etc/cron.deny

alice
bob

O uso do cron é controlado por /etc/cron.allow e /etc/cron.deny. As regras de decisão são as seguintes.

at é controlado da mesma forma com /etc/at.allow / /etc/at.deny. O arquivo *.allow tem precedência: quando existe, *.deny não é consultado.

anacron vs systemd timer

O cron funciona com a premissa de que a máquina está ligada, mas o anacron e o systemd timer podem compensar execuções perdidas enquanto estava desligada. Se o host não é um servidor sempre ligado, esses dois valem a pena considerar.

anacron

/etc/anacrontab tem uma sintaxe diferente do cron: usa quatro campos, "período (dias), atraso (minutos), identificador-da-tarefa, comando".

cat /etc/anacrontab

# periodo  atraso  identificador-da-tarefa  comando
1	5	cron.daily	run-parts --report /etc/cron.daily
7	25	cron.weekly	run-parts --report /etc/cron.weekly
@monthly 45	cron.monthly	run-parts --report /etc/cron.monthly

O primeiro campo é "quantos dias entre execuções" e o segundo é "o atraso (minutos) a esperar após a inicialização". O anacron não pode especificar minutos ou um horário exato; ele tem apenas granularidade de dias. Ele registra a data da última execução em /var/spool/anacron/ e, se o intervalo foi excedido, executa a tarefa na inicialização.

systemd timer

Um timer do systemd consiste em duas units: uma unit .timer e uma unit .service que faz o trabalho real.

systemctl list-timers

NEXT                        LEFT     LAST                        PASSED   UNIT             ACTIVATES
Sat 2026-05-31 03:00:00 UTC 8h left  Fri 2026-05-30 03:00:00 UTC 15h ago  backup.timer     backup.service

OnCalendar= dentro do .timer especifica o horário de execução. OnCalendar=*-*-* 03:00:00 significa diariamente às 3:00, e OnCalendar=daily é equivalente. systemctl list-timers lista a próxima execução, a última execução e o serviço associado. O ponto forte do systemd timer é que ele lida com controle de dependências, inspeção de logs via journalctl e execuções de recuperação (como o anacron) com Persistent=true.

Erros Comuns e Correções

Sintoma: Um script que "deveria" rodar sob o cron não roda (problema do PATH)

Causa: O PATH do shell que o cron inicia é mais curto que o de um shell de login interativo, e /etc/profile e .bashrc não são carregados. O comando não é encontrado e falha

Verificação:

* * * * * env > /tmp/cron-env.txt

Correção: Escreva comandos com caminho absoluto (/usr/local/bin/backup, não backup). Ou defina PATH=... explicitamente no topo do crontab.

Sintoma: Variáveis de ambiente no script estão indefinidas e ele se comporta incorretamente

Causa: O cron não herda as variáveis de ambiente do shell interativo (configurações personalizadas de LANG, HOME, etc.). Um script que assume um shell de login se comporta inesperadamente

Verificação:

crontab -l

Correção: Defina as variáveis necessárias explicitamente no script, ou escreva LANG=ja_JP.UTF-8 e similares no crontab. Para reproduzir um ambiente de login, inicie com bash -lc 'command'.

Sintoma: Tudo após % no crontab é ignorado / o comando é cortado

Causa: Em um crontab, um % na linha de comando é tratado especialmente como uma quebra de linha (um separador para a entrada padrão)

Verificação:

crontab -l

Correção: Para passar um % literal, escape com barra invertida como \%. Escreva como date +\%Y\%m\%d.

Sintoma: Uma tarefa especificando dia da semana e dia do mês roda em dias inesperados

Causa: No cron, quando ambos "dia do mês" e "dia da semana" estão definidos como algo diferente de *, a tarefa roda em um dia onde qualquer um corresponde (OR, não AND)

Verificação:

crontab -l

Correção: Entenda que o comportamento OR é por design. Para uma condição AND como "um dia da semana específico e uma data específica", verifique a data dentro do comando e controle lá.

Sintoma: Saída do cron (erros) é invisível

Causa: O cron envia a saída padrão e erro padrão de uma tarefa por email local para o usuário. Você não notará a menos que leia esse email

Verificação:

grep CRON /var/log/syslog

Correção: Redirecione a saída para um arquivo (>> /var/log/myjob.log 2>&1). Escrever MAILTO=address no crontab muda o destinatário, e MAILTO="" suprime o email.

Checklist de Conclusão

• [ ] Editou o crontab do usuário com crontab -e e verificou com crontab -l
• [ ] Confirmou que o crontab do sistema (/etc/crontab) tem um campo de usuário
• [ ] Registrou uma tarefa com at e gerenciou com atq / atrm
• [ ] Entendeu a precedência de /etc/cron.allow / cron.deny
• [ ] Escreveu scripts com caminhos absolutos para evitar o problema do PATH
• [ ] Verificou timers do systemd com systemctl list-timers

Resumo

O agendamento de tarefas é a base para automatizar operações do sistema. Combinado com gerenciamento de logs e prioridade de processos, ele eleva a confiabilidade da operação desassistida a outro nível.

Próximas Leituras

• Logs do Sistema: journald e rsyslog
• Prioridades de Processos: Como nice e renice Funcionam
• Shell Environment Variables