Analisador de expressões cron

Cinco campos, o mais grosseiro no fim

Dentro de um campo: * é qualquer, , enumera valores, - dá um intervalo e / avança em passos. */15 no campo dos minutos é de quinze em quinze minutos; 5/10 significa a partir de 5, de dez em dez, ou seja 5, 15, 25 e por aí fora. Os intervalos podem dar a volta, portanto FRI-MON é uma forma válida de dizer o fim-de-semana mais as suas pontas.

A regra que apanha toda a gente

É esta a única coisa que vale a pena levar desta página.

Quando ambos os campos — dia do mês e dia da semana — estão restringidos, o cron corre a tarefa quando qualquer um deles coincide. Não os dois. É um OU, e lê-se como um E.

0 0 1 * MON   # NOT "the 1st, if it is a Monday"
              # Actually: every 1st, AND every Monday

Esse agendamento dispara umas cinco vezes por mês. Cole-o no analisador acima e olhe para as próximas execuções — a sequência denuncia-o imediatamente.

A regra só se aplica quando ambos os campos estão restringidos. Se um deles for *, manda simplesmente o outro, e é por isso que 0 0 * * MON se comporta exactamente como se espera. O comportamento está na especificação POSIX e todos os cron correntes o implementam, portanto não é um defeito que se desligue nas configurações.

Para exigir mesmo as duas condições, restrinja um campo no agendamento e verifique o outro no início da tarefa:

0 0 * * MON  [ "$(date +\%d)" = "01" ] && /usr/local/bin/job

A mudança de hora, que parte tarefas duas vezes por ano

O cron corre no fuso horário local do servidor salvo indicação em contrário, e a hora local não é contínua. Quando os relógios adiantam, desaparece uma hora: uma tarefa marcada para as 02:30 pode ser saltada por completo ou disparar às 03:30, conforme o cron que tiver. Quando atrasam, a 01:30 acontece duas vezes, e a tarefa pode acontecer também.

O Vixie cron moderno faz um esforço — as tarefas perdidas por um salto para a frente costumam correr uma vez a seguir — mas o comportamento não é consistente entre implementações, e os agendadores de contentores variam outra vez.

A correcção duradoura é correr o agendador em UTC e converter nas pontas. Os CronJobs do Kubernetes usam UTC por omissão exactamente por isto. Se uma tarefa tiver mesmo de correr a uma hora local específica, aceite que ficará uma hora ao lado durante parte do ano, ou use um agendador que perceba fusos horários a sério — os temporizadores do systemd percebem.

Outras razões para uma tarefa cron não correr

• O ambiente está quase vazio. O cron não carrega o perfil da sua shell, portanto o PATH é mínimo e o seu ambiente virtual não está activo. Use sempre caminhos absolutos.
• Um sinal de percentagem solto. Numa crontab, % significa mudança de linha. date +%Y parte-se em silêncio; tem de ser date +\%Y.
• Sem mudança de linha final. Alguns cron ignoram a última linha de uma crontab que não termine numa.
• A saída vai para lado nenhum. O cron envia a saída por correio ao utilizador, e se o correio não estiver configurado ela desaparece. Redireccione para um ficheiro de registo para que as falhas se vejam.
• Execuções sobrepostas. O cron não espera que a execução anterior acabe. Uma tarefa de cinco minutos num agendamento de um minuto acumula-se até algo ceder. Use flock.

O que o cron não consegue exprimir

Os campos são independentes, portanto tudo o que não divida certo numa hora ou num dia fica fora de alcance. «De 90 em 90 minutos» não se escreve. Nem «a última sexta-feira do mês» no cron padrão — é para isso que existem o L e o # do Quartz, e é por isso que não são portáveis.

Se der por si a lutar com a sintaxe, isso costuma ser o sinal para passar a um agendador que pense em intervalos e não em campos de calendário. Um temporizador do systemd com OnUnitActiveSec=90min diz o que queria dizer numa linha.

Relacionado

As horas de execução acima estão em UTC — o conversor de marcas temporais passa qualquer uma delas para o seu fuso, ou para o formato que o seu agendador usa nos registos. Para comparar texto em vez de agendar, o testador de regex fica mesmo ao lado.