Evite jobs de cron às 2:00 e 3:00 (2013)

• Texto alertando sobre falhas em jobs de cron durante a transição do horário de verão (DST) em servidores Linux
• Duas vezes por ano, quando o fuso horário muda às 2h ou 3h da madrugada de domingo, jobs de cron podem ser executados em duplicidade ou simplesmente não rodar
• Em um caso real, no ambiente vixie-cron, jobs entre 3:00 e 3:01 foram repetidos 60 vezes em intervalos de 1 segundo, causando congestionamento de e-mails
• Como solução, propõe-se configurar o fuso como UTC ou evitar jobs nesse horário, além de desenvolver um scheduler open source melhor
• Um caso que relembra administradores de servidores e engenheiros de DevOps sobre a importância de gerenciar os riscos de mudanças de fuso horário

---

Conflito entre horário de verão e jobs de cron

• Se você agenda jobs para 2h ou 3h da madrugada de domingo, eles podem coincidir com a transição do horário de verão (DST) e causar falhas inesperadas de execução
  • Quando o DST começa, o relógio avança uma hora; quando termina, volta uma hora, gerando duplicação ou ausência de horários
  • Isso pode fazer com que jobs em determinados horários rodem duas vezes ou não rodem de forma alguma
• Em especial, jobs executados semanalmente na madrugada de domingo são afetados pelas duas transições anuais de DST
  • Em geral funcionam normalmente, mas no dia da mudança podem ocorrer repetições anormais de execução

Caso real: problema de repetição no vixie-cron

• Foi relatado, em ambiente Linux com vixie-cron, um caso em que jobs entre 3:00 e 3:01, no início do DST, foram executados cerca de 60 vezes em intervalos de 1 segundo
  • Os jobs passaram a conflitar entre si, gerando confusão como uma avalanche de alertas por e-mail
  • Felizmente, como os jobs não eram críticos, não houve dano ao sistema
• Esse tipo de problema decorre da estrutura simples de agendamento baseada em horário do cron
  • O cron não entende mudanças de fuso nem transições de DST; ele apenas executa no horário configurado

Soluções e alternativas possíveis

• A forma mais simples é não agendar jobs entre 2h e 3h da madrugada de domingo
  • Evitando esse intervalo, é possível escapar completamente dos problemas de execução duplicada causados pela mudança de DST
• Configurar o fuso horário do servidor como UTC também é uma alternativa eficaz
  • O UTC não adota horário de verão, então não há mudança de hora
• Como solução mais estrutural, o texto propõe desenvolver um scheduler de jobs mais inteligente
  • Seria necessário um substituto open source com recursos como prevenção de duplicidade, limitação de tempo de execução e reconhecimento de fuso horário

Proposta de longo prazo: abolir o horário de verão

• O autor apresenta a extinção do DST em nível governamental como a solução mais desejável
  • Mudar o relógio duas vezes por ano cria complexidade desnecessária tanto para a operação de sistemas quanto para a vida das pessoas
• Mas, enquanto o DST continuar existindo, administradores de sistemas e engenheiros de DevOps precisam tomar medidas preventivas
  • Principalmente em tarefas dependentes de horário, como jobs automatizados em lote, backups e rotação de logs

Conclusão: princípios para um agendamento seguro com cron

• Evite jobs no intervalo entre 2:00 e 3:00 durante a transição de DST
• Sempre que possível, use servidores operando em UTC para eliminar problemas de fuso horário
• Reconheça as limitações do cron e avalie adotar ferramentas de agendamento mais robustas
• Em ambientes DevOps, gerenciar fusos horários e garantir a confiabilidade da automação é uma tarefa essencial

[semjei]

Depois que tive problemas com uma tarefa agendada para as 2 da madrugada (uma vez executava duas vezes e outra vez não executava), passei a evitar esse horário sem falta.

[GN⁺]

Comentários do Hacker News

• Acho que o DST (horário de verão) é uma política completamente equivocada
  Não resolve problema nenhum e só causa inconveniência
  Bastaria fixar o horário padrão e, em vez disso, adiantar o horário de trabalho em uma hora, como no verão
  Por exemplo, abrir a loja às 6 em vez de 7 e fechar às 9 em vez de 10
  De qualquer forma já existe um período de adaptação duas vezes por ano, então bastaria mudar uma vez só
  Eu quero ver mais luz do sol depois do trabalho. No inverno, então, ainda mais, e não me importo se o sol nasceu durante o trajeto para o trabalho
  Vou ficar preso em ambiente fechado por 9 horas, então quero sol quando tiver tempo livre

  • Todo mundo odeia o DST, mas as alternativas propostas já foram testadas
    Por exemplo, houve a experiência de DST o ano inteiro nos EUA entre 1973 e 1975
    No começo, o apoio público era alto por razões como economia de energia e redução da criminalidade,
    mas a opinião pública piorou rapidamente por causa dos acidentes no trajeto escolar em manhãs escuras, e a medida acabou revogada
    (citação da Wikipedia)
  • Fico na dúvida se a proposta de não mexer no relógio e mudar o horário de funcionamento não produz no fim o mesmo efeito
    No fundo, isso soa como querer um deslocamento de horário ainda maior
  • O termo “horário de inverno” na verdade não existe
    Só existem horário padrão e horário de verão
    Dizer que se quer manter sempre o “horário de inverno” não soa psicologicamente atraente
  • O DST é apenas uma gambiarra para tentar alinhar tudo ao horário em que o sol nasce
    As pessoas querem começar o dia quando já está claro
    Programadores sofrem por causa do DST, mas acho que isso é uma questão de saber lidar bem com edge cases
  • O debate entre horário padrão e horário de verão no fim existe por falta de liberdade para escolher o horário de trabalho
    Como cada pessoa tem um padrão de sono diferente, se cada um pudesse escolher o horário que combina melhor consigo, haveria menos conflito

• Quando configurei os servidores do reddit no passado, defini tudo para o fuso do Arizona
  Como o Arizona não usa DST, a diferença para a Califórnia era de apenas 1 hora
  O motivo de não usar UTC era que, ao ler logs, “é mais fácil subtrair 1 do que subtrair 8”
  Hoje isso já foi mudado para UTC porque agora existe uma equipe global

  • Já tomei uma decisão parecida e depois sofri para arrumar a bagunça
    O melhor é padronizar tudo em UTC desde o início
  • Mas existe também o risco de a definição do fuso mudar, como no caso do Arizona
    Esse tipo de mudança acontece com frequência no mundo inteiro e, do ponto de vista de quem desenvolve app de calendário, é realmente um pesadelo
  • Me incomoda que a UI do visualizador de logs force o formato 12/24 horas com base na configuração de idioma do navegador
    Se a pessoa escolheu UTC, deveria se presumir que ela entende o formato YYYY-MM-DD em 24 horas
  • Em Java, dá para definir o fuso padrão no nível da JVM,
    mas como dentro da organização cada um mudava para PST no próprio ambiente, surgiu a confusão de cada log mostrar um horário diferente
    No fim, a liderança interveio e padronizou todos os aplicativos e bancos de dados em PST
  • Ao ler logs em UTC, ainda me confunde o fato de a data não virar
    Mesmo assim, hoje eu já interpreto UTC quase por instinto

• No passado, configurei os servidores da empresa em BST (horário de verão britânico) e usei bastante cron,
  e a confusão se repetia duas vezes por ano
  No fim, nunca conseguimos corrigir isso antes de a empresa quebrar
  A lição é simples — use UTC, a menos que exista um motivo especial para não usar

  • Tenho um relógio analógico em UTC na mesa para consultar quando olho logs
  • Às vezes usa-se o horário local porque o cliente não está em UTC
    Por exemplo, reset de limite de uso ou jobs em lote de cobrança rodam com base no horário regional
  • Acho melhor nem usar cron, e sim um agendador que entenda os dados e as configurações do cliente
  • Alguns relatórios precisam mesmo ser baseados no horário local
    Por exemplo, um relatório das 8h no Reino Unido muda de referência em UTC conforme o DST
    Portanto, UTC sozinho não resolve; é preciso armazenar também a informação de fuso horário
  • Em áreas como o mercado financeiro, em que o horário de abertura do mercado importa, UTC sozinho não basta

• Em alguns países (Cuba, Egito, Líbano), a mudança de DST acontece à meia-noite
  (link relacionado)

  • Fiquei surpreso ao saber que há lugares em que a mudança de DST não ocorre à meia-noite
    No Brasil, era comum mudar em 00:00~01:00 ou 00:00~23:00
  • As regras de fuso horário realmente fazem muita coisa imprevisível

• Há estudos mostrando que, nos dias de ajuste do DST, a mortalidade e as visitas ao pronto-socorro aumentam muito
  (artigo da ScienceAlert)
  Ou seja, isso vai muito além de um problema de cron; o DST é também uma política ruim para a saúde

• Esse problema já tinha sido resolvido há muito tempo no OpenBSD e no Debian
  No manual do cron(8) do Debian há uma explicação da lógica de tratamento de mudanças de horário menores que 3 horas durante ajustes de DST
  (link do patch,
  manual,
  relatório de bug)

  • Nesse caso, parece que o autor do texto original estava usando uma distribuição sem esse patch aplicado

• O conselho é não agendar jobs à meia-noite (00:00)
  Como a data pode causar confusão, é melhor usar horários quebrados como 00:01 ou 01:45

  • Eu também configuro meus jobs de cron em horários como XX:13, XX:23, XX:42
    Assim fica mais fácil rastrear a causa quando o sistema apresenta algo estranho em um horário específico
  • Quase nunca vi 00:00 causar problema
    Ainda assim, em ambientes que usam relógio de 12 horas, isso pode gerar confusão

• Antes de passar por problemas com fuso horário, eu não sabia, mas
  no mundo existem horários inexistentes e horários ambíguos
  Por exemplo, quando se pula de 2h para 3h, 2h30 não existe,
  e, quando o relógio volta, 2h30 acontece duas vezes
  O horário do ajuste de DST varia de país para país, então há casos como o do Chile, em que a meia-noite desaparece
  (blog relacionado)
  Lembro que Java e Ruby tratavam essa situação de forma diferente e, no começo da minha época na Stripe, isso causou três incidentes seguidos

• Em jobs de cron, evito horários cheios e, quando possível, agendo depois das 4 da manhã ou antes da meia-noite
  Em infraestrutura compartilhada, a disputa por recursos em horários exatos tende a ser maior

  • A opção RandomizedDelaySec do systemd ajuda a reduzir colisões
  • Também é uma boa ideia colocar algo como sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ; antes do comando do cron
    para aplicar um atraso aleatório de 0 a 59 minutos

• Sempre que possível, jobs agendados importantes devem ser idempotentes (seguros para execução duplicada)
  Especialmente quando há sistemas de fila envolvidos, esse tipo de projeto é essencial para prevenir problemas