O agendamento de tarefas é uma das funcionalidades mais poderosas do Linux, permitindo que scripts sejam executados automaticamente em horários específicos ou intervalos regulares. O cron é o serviço responsável por isso, e o crontab é a ferramenta que usamos para gerenciar as tarefas agendadas. Nesta aula, vamos mergulhar no universo do cron, entendendo sua sintaxe, configuração e boas práticas para que você possa automatizar rotinas com confiança e eficiência.

Dominar o cron é essencial para qualquer administrador de sistemas ou desenvolvedor que deseja criar soluções autônomas, como backups, atualizações, relatórios e limpezas de arquivos. Além de aprender a agendar, você verá como lidar com variáveis de ambiente, que muitas vezes causam confusão, e como interpretar os logs para diagnosticar problemas.

crontab

O crontab é o arquivo que contém as instruções de agendamento para o cron. Cada usuário do sistema pode ter seu próprio crontab, e o comando crontab é usado para criar, editar, listar ou remover essas configurações. O crontab do sistema (para root) fica em /etc/crontab, mas o mais comum é usar o crontab por usuário, acessível via crontab -e.

Para visualizar as tarefas agendadas do usuário atual, use crontab -l. Para editar, crontab -e (que abre um editor de texto, geralmente o vi ou nano). Para remover todas as tarefas, crontab -r. É importante notar que o crontab é um arquivo simples de texto, mas com regras rígidas de formatação. Cada linha não comentada representa um agendamento, e os comentários começam com #.

Aqui está um exemplo de como criar um crontab para o usuário atual:

# Abre o editor para editar o crontab
crontab -e

# Adicione uma linha para rodar um script todos os dias às 2h da manhã
0 2 * * * /caminho/para/script.sh

# Salve e saia. O cron carregará automaticamente as novas configurações.

Além do crontab por usuário, existem diretórios especiais em /etc/cron.d, /etc/cron.hourly, /etc/cron.daily, etc., para scripts que devem ser executados com frequência. Esses diretórios são gerenciados pelo sistema e são úteis para tarefas de manutenção.

Sintaxe de agendamento

A sintaxe do crontab é composta por cinco campos que definem quando o comando será executado: minuto, hora, dia do mês, mês e dia da semana. Cada campo pode conter um número específico, uma lista (separada por vírgulas), um intervalo (com hífen), um passo (com barra) ou um asterisco (que significa "qualquer valor").

Os campos são:

  • Minuto (0-59)
  • Hora (0-23)
  • Dia do mês (1-31)
  • Mês (1-12 ou jan-dez)
  • Dia da semana (0-7, onde 0 e 7 são domingo, ou nomes como sun-sat)

Exemplos práticos:

# Executar todo dia à meia-noite
0 0 * * * comando

# Executar a cada 5 minutos
*/5 * * * * comando

# Executar às 8h e às 18h de segunda a sexta
0 8,18 * * 1-5 comando

# Executar no dia 1º de cada mês às 3h15
15 3 1 * * comando

# Executar a cada hora em ponto
0 * * * * comando

É crucial entender a diferença entre dia do mês e dia da semana: quando ambos são restringidos, o comando é executado se qualquer um dos dois coincidir (ou seja, uma condição OU). Por exemplo, 0 0 1 * 1 executa no dia 1 de qualquer mês e em todas as segundas-feiras, não somente quando o dia 1 cair numa segunda.

Para facilitar a criação, você pode usar nomes abreviados para meses e dias da semana (jan, feb, mar, etc. e sun, mon, tue, etc.), embora seja mais comum usar números. Lembre-se de que o cron não interpreta variáveis de ambiente automaticamente, então caminhos absolutos são recomendados.

Variáveis de ambiente em cron

Um dos problemas mais comuns ao agendar scripts é que o ambiente do cron é muito limitado. Por padrão, o cron executa comandos com um PATH mínimo (/usr/bin:/bin) e sem as variáveis de ambiente do usuário, como HOME, USER, ou variáveis personalizadas. Isso pode causar falhas em scripts que dependem de caminhos definidos no shell.

Para contornar isso, você pode definir variáveis de ambiente diretamente no crontab. No início do arquivo, antes das linhas de agendamento, você pode adicionar linhas no formato NOME=valor. Por exemplo:

# Define o PATH completo
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Define o HOME
HOME=/home/usuario

# Define uma variável personalizada
MEU_SCRIPT=/home/usuario/meu_script.sh

Essas variáveis serão aplicadas a todos os comandos agendados no crontab. Além disso, é uma boa prática usar caminhos absolutos no comando ou invocar o script com o interpretador correto, como /bin/bash /caminho/script.sh.

Outra abordagem é criar um script wrapper que configure o ambiente antes de executar a tarefa real. Por exemplo, um script run_tarefa.sh que faz source ~/.bashrc e depois chama o script principal. Isso garante que todas as variáveis do usuário estejam disponíveis.

Logs

Para monitorar se as tarefas agendadas estão sendo executadas corretamente, é essencial revisar os logs. O cron registra suas atividades no syslog, geralmente em /var/log/syslog ou /var/log/cron, dependendo da distribuição. Você pode visualizar as últimas entradas com:

grep CRON /var/log/syslog
# ou
tail -f /var/log/syslog | grep CRON

Além disso, é altamente recomendável redirecionar a saída dos seus scripts para arquivos de log, para que você possa analisar o que aconteceu. Por padrão, se não houver redirecionamento, o cron envia a saída padrão e os erros por e-mail para o usuário (se o postfix estiver configurado). Para evitar isso, você pode redirecionar a saída para um arquivo:

0 2 * * * /caminho/script.sh >> /var/log/meu_script.log 2>&1

O >> anexa ao arquivo, e 2>&1 redireciona tanto a saída padrão quanto os erros para o mesmo arquivo. Você também pode usar MAILTO="" no crontab para desabilitar o envio de e-mails.

Para testar se o cron está executando, você pode criar uma tarefa simples que escreve a data em um arquivo a cada minuto:

* * * * * echo "$(date) - tarefa executada" >> /tmp/cron_test.log

Depois de alguns minutos, verifique o conteúdo de /tmp/cron_test.log.

Boas práticas e observações finais

Ao trabalhar com cron, algumas práticas podem evitar dores de cabeça:

  • Sempre use caminhos absolutos para comandos e scripts.
  • Teste o script manualmente antes de agendar.
  • Redirecione a saída para logs para facilitar o diagnóstico.
  • Defina variáveis de ambiente no crontab quando necessário.
  • Evite agendar tarefas que dependem de horários de pico, como backups durante o dia.
  • Use MAILTO para receber notificações em caso de erro, se desejar.

Lembre-se de que o cron não é a única ferramenta de agendamento; existem alternativas como systemd-timers e anacron, mas o cron é amplamente usado e suficiente para a maioria dos casos.

Referências

Exercícios

  1. Explique a diferença entre o crontab do usuário e os diretórios em /etc/cron.daily.

    ✓ Resposta: O crontab do usuário é específico para cada usuário e pode ser editado com crontab -e. Já os diretórios como /etc/cron.daily são gerenciados pelo sistema e executam scripts que estão dentro deles em intervalos definidos (diariamente, horariamente, etc.), geralmente controlados pelo /etc/anacrontab ou pelo próprio cron. Eles são usados para tarefas globais do sistema.

  2. Crie uma linha de crontab para executar um script chamado /home/aluno/backup.sh todos os dias às 3:30 da manhã, de segunda a sexta-feira.

    ✓ Resposta: 
    30 3 * * 1-5 /home/aluno/backup.sh

  3. Qual é o efeito de definir MAILTO="" no crontab?

    ✓ Resposta: Definir MAILTO="" desativa o envio de e-mails com a saída das tarefas. Sem isso, o cron envia a saída padrão e erros para o e-mail do usuário (ou para o endereço especificado). Com MAILTO="", nenhum e-mail é enviado, o que é útil quando você redireciona a saída para arquivos de log.

  4. Escreva um comando crontab para executar /usr/bin/atualizar.sh a cada 10 minutos durante os dias úteis (segunda a sexta), das 9h às 18h.

    ✓ Resposta: 
    */10 9-18 * * 1-5 /usr/bin/atualizar.sh

  5. Por que é importante redirecionar a saída de um script agendado para um arquivo de log?

    ✓ Resposta: Redirecionar a saída para um arquivo de log permite que você acompanhe o que aconteceu durante a execução, identifique erros e sucessos, e facilite o diagnóstico de problemas. Sem redirecionamento, a saída é enviada por e-mail (ou descartada), o que pode ser inconveniente e ineficiente. Além disso, logs persistentes são úteis para auditoria e monitoramento.