O que é que esta expressão cron faz, afinal?

O cron normal lê-se da esquerda para a direita como minuto, hora, dia do mês, mês, dia da semana. Alguns escalonadores — este incluído — aceitam um campo inicial opcional de segundos, ficando seis no total. Cada campo aceita um número, uma lista separada por vírgulas, um intervalo (1-5), um passo (*/15) ou uma combinação (10-50/10). Os campos de mês e de dia da semana também aceitam nomes: JAN-DEC e SUN-SAT (ou 0-7, em que tanto 0 como 7 significam domingo).

* significa «qualquer valor» para esse campo — * * * * * dispara a cada minuto. */15 significa «de 15 em 15 valores a partir do mínimo do campo» — nos minutos, isso dá :00, :15, :30, :45.

O cron simples — o da sua crontab — tem 5 campos, com um limite mínimo de uma execução por minuto. Algumas ferramentas (esta, e coisas como o node-cron) aceitam um sexto campo, à cabeça, para os segundos, que é a única forma de exprimir «a cada 10 segundos» em sintaxe cron. É fácil confundir os dois: 0 30 2 * * * parece querer dizer 2:30, mas com seis campos o primeiro 0 são segundos e o agendamento dispara às 02:30:00 — que, escrito em cron de 5 campos, seria 30 2 * * *. Contar mal os campos é a maneira mais comum de agendar a tarefa certa para a hora errada.

Os atalhos @ — @hourly, @daily, @weekly, @monthly, @yearly (@annually e @midnight são sinónimos) — expandem-se para expressões de cron normal fixas e comportam-se de forma idêntica. O @reboot é outra história; veja mais abaixo.

0 0 13 * 5 lê-se como «no dia 13, se for uma sexta-feira» — sexta-feira 13. Não é. O cron normal trata o dia do mês e o dia da semana como um OU sempre que ambos estão restringidos: a tarefa dispara no dia 13 de cada mês e a todas as sextas-feiras, o que na maioria dos meses dá cinco ou seis execuções em vez da única que estava a imaginar.

Isto só morde quando os dois campos estão restringidos ao mesmo tempo. 0 0 13 * * (todos os dias 13, com o dia da semana deixado a *) significa exatamente o que parece, e o mesmo vale para 0 0 * * 5 (todas as sextas). É a combinação que troca silenciosamente o E pelo OU, e é uma das surpresas mais antigas do cron — o POSIX especifica-a, todas as implementações de cron importantes seguem-na, e continua a apanhar gente que aprendeu a programar bem depois de a maioria das especificações POSIX ter sido escrita.

O cron agenda em hora de relógio, e a hora de relógio não é contínua numa mudança para a hora de verão. Duas vezes por ano, algures, um relógio salta uma hora ou repete uma — e uma tarefa agendada dentro dessa hora tem de fazer alguma coisa, porque «corre à mesma» não tem significado inequívoco.

Quando os relógios avançam, as horas de relógio saltadas não existem. Uma tarefa marcada para as 02:30 no dia em que Europe/Paris salta das 02:00 para as 03:00 simplesmente não tem 02:30 em que correr — esta ferramenta reporta essa execução como saltada em vez de a mover em silêncio para as 01:30 ou para as 03:30, porque qualquer dos palpites estaria errado pelo menos tantas vezes quantas estaria certo.

Quando os relógios recuam, as horas de relógio repetidas acontecem duas vezes. Esta ferramenta segue a convenção de todas as implementações de cron que conhecemos: dispara uma vez, na primeira ocorrência, e não duas.

A solução prática é aborrecida mas fiável: agende as tarefas de manutenção fora da janela das 00:00 às 04:00, onde a maioria das regiões coloca a sua mudança de hora, ou ponha a sua infraestrutura em UTC de uma ponta à outra, onde esta secção inteira deixa de se aplicar.

O @reboot corre uma vez, quando a máquina arranca — o próprio cron não garante mais nada além disso, e não tem noção de «próxima execução» para ele porque não existe nenhuma. Isso torna-o mau candidato ao padrão habitual de monitorização, o «avisa-me se isto não correr à hora prevista»: não há hora prevista, portanto não há nada contra que comparar um silêncio. Se uma tarefa @reboot é importante — restaurar estado depois de uma queda, por exemplo — o que vale a pena monitorizar costuma ser o estado que ela restaura, e não o arranque em si.

Isto precisa de conta?

Não. Não há registo nem limite de pedidos digno de nota, porque nada aqui fala com um servidor — a análise e o cálculo das próximas execuções acontecem ambos no seu navegador.

Guardam as expressões que eu testo?

Não. Nada do que escreve é enviado para lado nenhum, por isso não há nada para guardar nem nada que nos possa pedir para apagar.

Porque é que às vezes mostra menos de 8 execuções?

Há um punhado de expressões que descrevem um agendamento que dispara raramente, ou nunca. 0 0 31 2 * (31 de fevereiro) nunca corresponde a uma data real e devolve zero execuções. 0 0 29 2 * (29 de fevereiro) só corresponde a anos bissextos, por isso pode ser preciso procurar durante alguns anos até aparecer a próxima execução.

Que extensões de cron é que isto não suporta?

Os extras ao estilo Quartz que alguns escalonadores acrescentam por cima do cron POSIX: L (último dia), W (dia útil mais próximo), # (n-ésimo dia da semana do mês) e ? (sem valor específico). Esta ferramenta assinala-os explicitamente em vez de os ler mal em silêncio como se fossem outra coisa.

O meu servidor usa um fuso horário diferente do que escolhi aqui — isso importa?

Sim, e vale a pena confirmar. O cron numa máquina Linux típica corre no fuso horário configurado no sistema, que não é necessariamente UTC nem necessariamente o seu. Escolha o fuso em que a crontab da tarefa corre de facto, e não o fuso em que calha estar sentado, ou as horas de execução que esta ferramenta mostra não vão bater certo com a realidade.