O CentOS 5.4 manipula corretamente os segundos bissextos?

Question

Aparentemente, o IERS anunciou um segundo bissexto devido à meia-noite de 30 de junho deste ano.

O CentOS / RHEL 5.4 é atualizado corretamente para oferecer suporte / transição junto com os sistemas NTP atualizados? Eu estava com a impressão de que precisaria de um pacote tzdata atualizado, mas não tinha certeza.

ATUALIZAÇÃO:

Eu verifiquei o log de alterações do pacote tzdata e observei o seguinte:

* Tue Feb 27 2007 Petr Machata <[email protected]> - 2007c-1
- Upstream 2007c
  - Pulaski County, Indiana, switched back to eastern time.
  - Turkey switches at 01:00 standard time, not at 01:00 UTC.
- Upstream 2007b
  - Changes to the commentary in "leapseconds".
- Resolves: #230089


* Tue Aug 22 2006 Petr Machata <[email protected]> - 2006j-1
- Upstream 2006j
  - Honduras stopped observing DST on Monday at 00:00
  - America/Bermuda will follow the US's lead next year
  - America/Moncton will use US-style rules next year
  - New Zone America/Blanc-Sablon, for Canadians who observe AST all
    year
  - New zone: America/Atikokan instead of America/Coral_Harbour
  - New zones: Europe/Jersey, Europe/Guernsey, Europe/Isle_of_Man
  - Historical changes
  - Commentary updates
- Upstream 2006i
  - localtime.c fixes
- Upstream 2006h
  - zic leapsecond fix

O "zic leapsecond fix" está relacionado?

    

Answer 1

Sua pergunta é respondida na base de conhecimento da Red Hat:

link

Sinopse:
Existe um problema em potencial conhecido para algumas versões do RHEL 4 e 5, que podem fazer com que o kernel trave à meia-noite em sistemas que também estejam executando o NTP. Se você tiver um patch maior do que 5.4 e 4.8, você deve estar ok (assumindo que todos os arquivos relacionados apropriados estejam corrigidos corretamente). Alternativamente, você pode optar por não executar o NTP, mas precisará ter certeza de que o arquivo de dados tzdata foi atualizado para o nível apropriado.

Resumindo, se você estiver em um sistema totalmente atualizado, não deverá ter problemas.

Mais informações estão disponíveis no Red Hat Bugzilla: link

    

Answer 2

Você pode verificar se uma determinada atualização de segundo intercalado foi aplicada usando o comando zdump. No CentOS isso é

/usr/sbin/zdump -v right/UTC

Você está procurando uma linha semelhante a:

right/UTC  Sat Jun 30 23:59:60 2012 UTC = Sat Jun 30 23:59:60 2012 UTC isdst=0 gmtoff=0

Isso deve ser mencionado no changelog do pacote tzdata:

rpm -q --changelog tzdata | less

Em uma caixa CentOS 5.7 mal-corrigida, eu não encontrei esta atualização. No Ubuntu atual 11.10 e no Debian squeeze boxes, eu estou achando. YMMV.

Para saber mais sobre isso (de um PoV do Debian, mas ele deve se aplicar amplamente ao CentOS): link

    

Answer 3

Contanto que você tenha atualizado seu sistema, tudo bem. Além disso, o NTP deve garantir que tudo esteja sob controle.

    

Answer 4

Você não verá o salto de 2012 em segundo lugar nos arquivos de fuso horário, a menos que tenha instalado o pacote de erratas RHEL / CentOS "tzdata-2011n-2" ou posterior, lançado em março de 2012. Os pacotes mais antigos não o conhecem porque os segundos bissextos são anunciados apenas com 6 meses de antecedência. Além disso, para usar esses arquivos atualizados, suas caixas devem ser configuradas para usar um fuso horário "certo", por exemplo, "right / America / New_York".

Se seus sistemas estiverem executando o ntpd e seus servidores NTP upstream suportarem pré-anúncios de segundo salto , o ntpd instruirá o kernel a pular um segundo no momento apropriado. Qualquer aplicativo que use libc gettimeofday () verá o UTC 23: 59: 59.XXX repetido duas vezes.

Os servidores NTP upstream só começarão a anunciar o "indicador de salto" após 2012-06-30 00:00:00 UTC, já que o protocolo não permite mais nenhum aviso. Se os relógios de referência upstream estiverem com reconhecimento de leapsecond (por exemplo, GPS), o ntpd deve distribuir corretamente o indicador de salto para todos os hosts. Se as referências upstream não estiverem informadas (por exemplo, alguns relógios de pulso por segundo), e o operador ntpd do stratum 1 não configurou um arquivo "leapseconds". Se você tiver uma mistura de relógios de referência, qualquer um deles pode fornecer o indicador de salto.

    

Answer 5

Se você for atingido pelo bug do segundo bissexto e tiver uma carga alta nos servidores, pare o ntp e configure o tempo com o ntpdate, consulte aqui