Agendamento de Tarefas: cron, at e Timers do systemd

2026-05-30 Tempo de leitura: Cerca de 15 min Dificuldade: Intermediario

O Que Voce Vai Conquistar

• Ler e escrever a sintaxe do crontab (cinco campos)
• Explicar a diferenca entre um crontab de usuario e um crontab de sistema (/etc/crontab, /etc/cron.d)
• Gerenciar tarefas unicas com at / atq / atrm
• Decidir quando usar anacron e systemd timer
• Entender o controle de execucao com cron.allow / cron.deny
• Evitar armadilhas frequentes no exame como o "problema do PATH no cron"

Este e o nucleo do objetivo 107.2 do LPIC-1 "Automatizar tarefas de administracao do sistema por agendamento de tarefas". E a tecnica para executar trabalhos rotineiros, como backups regulares e rotacao de logs, automaticamente sem intervencao humana.

Qual Agendador Voce Deve Usar?

Para execucoes repetidas escolha cron, para uma unica execucao escolha at, para execucoes periodicas em uma maquina que nem sempre esta ligada escolha anacron, e para controle avancado em um ambiente systemd escolha systemd timer. Esse e o ponto de partida para a decisao.

cron pula uma tarefa se a maquina nao esta ligada no horario agendado. Em contraste, anacron julga por "dias decorridos desde a ultima execucao", portanto nao perde execucoes mesmo em ambientes como laptops que ficam desligados por periodos.

A Sintaxe do crontab

Cada linha do crontab consiste em seis elementos: "minuto hora dia mes dia-da-semana comando". Os cinco primeiros sao campos de tempo, e do sexto em diante e 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 utilizaveis em cada campo sao 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 voce tambem 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 usuario

crontab -e

crontab: installing new crontab

crontab -e abre um editor (definido por $EDITOR / $VISUAL) e edita o crontab do usuario atual. Ao salvar, ele e armazenado em /var/spool/cron/ (ou crontabs/ dependendo da distribuicao) e o daemon cron o detecta automaticamente. Adicionar a seguinte linha executa o backup diariamente as 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 confirmacao, e mais seguro manter uma copia com -l primeiro. Como root voce pode operar o crontab de outro usuario 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/ sao o crontab do sistema. Diferente do crontab de usuario, eles inserem um campo "executar como usuario" entre os campos de tempo e o comando (um layout de seis campos). Essa diferenca e 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 horario especificado. Digite o comando no prompt e confirme com Ctrl+D (<EOT>). Verifique a fila com atq (= at -l) e delete a tarefa numero 2 com atrm 2 (= at -d 2). O horario pode ser dado de forma flexivel, 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 e controlado por /etc/cron.allow e /etc/cron.deny. As regras de decisao sao as seguintes.

at e controlado da mesma forma com /etc/at.allow / /etc/at.deny. O arquivo *.allow tem precedencia: quando existe, *.deny nao e consultado.

anacron vs systemd timer

O cron funciona com a premissa de que a maquina esta ligada, mas o anacron e o systemd timer podem compensar execucoes perdidas enquanto estava desligada. Se o host nao e um servidor sempre ligado, esses dois valem a pena considerar.

anacron

/etc/anacrontab tem uma sintaxe diferente do cron: usa quatro campos, "periodo (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 e "quantos dias entre execucoes" e o segundo e "o atraso (minutos) a esperar apos a inicializacao". O anacron nao pode especificar minutos ou um horario exato; ele tem apenas granularidade de dias. Ele registra a data da ultima execucao em /var/spool/anacron/ e, se o intervalo foi excedido, executa a tarefa na inicializacao.

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 horario de execucao. OnCalendar=*-*-* 03:00:00 significa diariamente as 3:00, e OnCalendar=daily e equivalente. systemctl list-timers lista a proxima execucao, a ultima execucao e o servico associado. O ponto forte do systemd timer e que ele lida com controle de dependencias, inspecao de logs via journalctl e execucoes de recuperacao (como o anacron) com Persistent=true.

Erros Comuns e Correcoes

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

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

Verificacao:

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

Correcao: Escreva comandos com caminho absoluto (/usr/local/bin/backup, nao backup). Ou defina PATH=... explicitamente no topo do crontab.

Sintoma: Variaveis de ambiente no script estao indefinidas e ele se comporta incorretamente

Causa: O cron nao herda as variaveis de ambiente do shell interativo (configuracoes personalizadas de LANG, HOME, etc.). Um script que assume um shell de login se comporta inesperadamente

Verificacao:

crontab -l

Correcao: Defina as variaveis necessarias 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 apos % no crontab e ignorado / o comando e cortado

Causa: Em um crontab, um % na linha de comando e tratado especialmente como uma quebra de linha (um separador para a entrada padrao)

Verificacao:

crontab -l

Correcao: 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 mes roda em dias inesperados

Causa: No cron, quando ambos "dia do mes" e "dia da semana" estao definidos como algo diferente de *, a tarefa roda em um dia onde qualquer um corresponde (OR, nao AND)

Verificacao:

crontab -l

Correcao: Entenda que o comportamento OR e por design. Para uma condicao AND como "um dia da semana especifico e uma data especifica", verifique a data dentro do comando e controle la.

Sintoma: Saida do cron (erros) e invisivel

Causa: O cron envia a saida padrao e erro padrao de uma tarefa por email local para o usuario. Voce nao notara a menos que leia esse email

Verificacao:

grep CRON /var/log/syslog

Correcao: Redirecione a saida para um arquivo (>> /var/log/myjob.log 2>&1). Escrever MAILTO=address no crontab muda o destinatario, e MAILTO="" suprime o email.

Checklist de Conclusao

• [ ] Editou o crontab do usuario com crontab -e e verificou com crontab -l
• [ ] Confirmou que o crontab do sistema (/etc/crontab) tem um campo de usuario
• [ ] Registrou uma tarefa com at e gerenciou com atq / atrm
• [ ] Entendeu a precedencia 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 e a base para automatizar operacoes do sistema. Combinado com gerenciamento de logs e prioridade de processos, ele eleva a confiabilidade da operacao desassistida a outro nivel.

Proximas Leituras

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