Falha de ntpdate se o sistema estiver configurado para uma data posterior a 2038

Question

A data atual correta é .Fri 25 de março 12:11:07 CST 2016.

Quando altero a data para "2018/01/01", o ntpdate funciona corretamente.

Quando altero a data para " 2099/01/01 ", o ntpdate não funciona corretamente.

Ok:

[root@oldboylinux ~]# date -s "2018/01/01"
Mon Jan  1 00:00:00 CST 2018

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
25 Mar 12:06:22 ntpdate[7187]: step time server 216.229.0.179 offset -55857225.378947 sec

Não ok:

[root@oldboylinux ~]#date -s "2099/01/01"
Thu Jan  1 00:00:00 CST 2099

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
 1 May 18:36:59 ntpdate[7189]: step time server 216.229.0.179 offset 1682966210.024232 sec

seg 1 de maio 18:41:18 CST 2152 é uma data errada.

O ntpdate tem um intervalo efetivo?

    

Answer 1

Primeiro algumas notas:

• A versão atual do NTP (v4) opera usando eras.

• Uma era é de 136 anos, (segundos apresentáveis por um inteiro de 32 bits sem sinal). Ou aproximadamente

  60 * 60 * 24 * 365 * 136 = 4288896000 
                      2^32 = 4294967296
  
  4294967296 − 4288896000 = 6071296
   6071296 / 60 / 60 ∕ 24 ≈ 70 (days, not accounting for leaps)
  

• Era 0: A época principal , ou a data base de "era 0" , é 00:00 1 de janeiro de 1900 UTC.

• Era 1: começa no início do ano 2036. (Dois anos antes do UNIX-2038)
• Era 2: começa no início do ano 2172.
• etc. (Para alguns outros exemplos, consulte a página 14 do RFC 5905 .
• ntpdate usa carimbos de hora NTP que são 64 bits. 32 bits por segundo e 32 bits por frações.
• Um pouco confuso, talvez; NTP-date usa 128 bits e inclui era. Isso abrange a idade do universo e no futuro.

Como declarado na seção NTP do " problema do ano 2038 "- página da Wikipedia você tem um limite absoluto de 68 anos entre dois timbres de tempo NTP. (%código%). Porém, para eliminar a ambiguidade, deve-se usar uma faixa mais estreita.

Os carimbos de tempo NTP operam referenciando o tempo relativo e não absoluto; O servidor fornece uma correção para o cliente por um deslocamento relativo ao seu próprio tempo. Ou seja: não diz:

- A data é 26 de março de 2016

mas sim (simplificado como funciona o NTP):

- Você está fora em +123412512.918 segundos , ou:
- Você está fora por -2652221.3466 segundos , etc.

Ou para citar o RFC:

Timestamps are unsigned values, and operations on them produce a result in the same or adjacent eras. Era 0 includes dates from the prime epoch to some time in 2036, when the timestamp field wraps around and the base date for era 1 is established.

No seu caso, quando você tem o ano de 2099, você tem mais de 68 anos no futuro - aproximadamente 15 anos. Você acaba no ano 2152 e o que temos é:

 2152 - 2016 = 136 (One era)

Ou dito de outra forma:

                    2099 - 2036 = 63          (years into era 1)
        63 * 365 * 24 * 60 * 60 = 1986768000  (approx NTP time stamp for 2099)
       116 * 365 * 24 * 60 * 60 = 3658176000  (approx NTP time stamp for 2016)
       3658176000 - 1986768000  = 1671408000  (approx diff)
1671408000 / 60 / 60 / 24 / 365 = 53          (approx years)

1986768000 < 3658176000 thus add 1671408000

2099 + 53 = 2152 (the year your system was corrected to)

Então, sim, para responder à sua pergunta:

— Does ntpdate have an effective range?

Sim. ± 68 anos, embora o intervalo máximo efetivo seja um pouco mais estreito.

NTP em si mesmo é infinito.

Dê uma olhada em RFC 5905 se estiver interessado. Observe também que os RFCs obsoletos podem conter informações interessantes, como Apêndice E. A escala de tempo do NTP e sua cronometria no RFC 1305 .

(P.S: Em comparação com timestamps do UNIX, 136 / 2 = 68 .)

    

Answer 2

O que você está vendo é o "bug" comum conhecido como o problema do ano 2038, também conhecido como bug do Y2K38, que ainda está presente em servidores Linux de 32 bits.

Por volta do ano 2000, percebemos que, além do bug y2k / millenium, haveria outro bug relacionado ao tempo mais adiante. (sim, eu fiz parte de uma equipe de "prevenção" do y2k)

Como a época do Unix é um contador de 32 bits-segundo que começou em 1 de janeiro de 1970 e era apenas um inteiro de 32 bits assinado, ele tinha (e ainda possui em alguns sistemas) um limite superior de 03: 14:07 UTC em 19 de janeiro de 2038. link

Nas implementações mais recentes, ele foi ampliado para 64 bits.

Starting with NetBSD version 6.0 (released in October 2012), the NetBSD operating system uses a 64-bit time_t for both 32-bit and 64-bit architectures. Applications that were compiled for an older NetBSD release with 32-bit time_t are supported via a binary compatibility layer, but such older applications will still suffer from the Year 2038 problem.[13]

OpenBSD since version 5.5, released in May 2014, also uses a 64-bit time_t for both 32-bit and 64-bit architectures. In contrast to NetBSD, there is no binary compatibility layer. Therefore, applications expecting a 32-bit time_t and applications using anything different from time_t to store time values may break.[14]

Linux uses a 64-bit time_t for 64-bit architectures only; the pure 32-bit ABI is not changed due to backward compatibility.[15] There is ongoing work, mostly for embedded Linux systems, to support 64-bit time_t on 32-bit architectures, too

Como uma história folclórica e um embuste bastante elaborado, John Titor foi enviado de volta no tempo para obter um mainframe para ajudar a corrigir problemas herdados no futuro devido ao bug de 2038, e previu uma guerra civil / nuclear americana sob o governo de Hillary Clinton em uma realidade paralela nossa.

link

John Titor’s story began in the year 2036. Titor belonged to a team of seven individuals selected to embark on a journey through time. He had lived through unimaginable horrors in a world destroyed by selfishness, cynicism, and corrupt government, ravaged by nuclear war. To make matters worse, what little remained of their technology was threatened by a looming UNIX timeout error in 2038.

Por favor, veja também o link

Systems employing a 32-bit type are susceptible to the Year 2038 problem, so many implementations have moved to a wider 64-bit type, with a maximal value of 263−1 corresponding to a point in time 292 billion years from now.

Voltando à sua pergunta sobre o ntpdate.

Sobre o limite de 2038. Portanto, o problema é que time_t era (é) um int assinado de 32 bits. isto é, um inteiro de 32 bits com o último bit dedicado ao sinal. Então, de fato, você pode armazenar apenas números (então número de segundos entre -0x7fffffff e + 7fffffff ([phone]). Então [phone] limita a representação do intervalo de tempo para 1 de janeiro de 1970 + 2147483647 segundos que se traduz em ntpdate sendo apenas capaz de armazenar em seu sistema de datas até 03:14:07 UTC em 19 de janeiro de 2038.

Sobre as datas após 2038, o problema é que as rotinas de código convertendo strings para a representação interna (time_t / 32 bit integer) são redefinidas para o dia / 0 segundo, dependendo da implementação da biblioteca.

Sobre o seu ano limite superior. time_t no seu sistema é um inteiro assinado, portanto a biblioteca está fazendo a verificação do limite superior como o valor de um inteiro não assinado, que aos [phone] segundos depois de 1 de janeiro de 1970 fornecerá um limite superior em algum lugar no ano 2106. Dependendo da implementação , a verificação pode realmente ser feita em cadeia mais ou o comportamento é devido às propriedades do inteiro de 32 bits, verificando apenas o código ntpdate.

INT_MAX (32 bits) = 2147483647
UINT_MAX (32 bits) = 4294967295 (0xffffffff)

De link

For example, changing time_t to an unsigned 32-bit integer, which would extend the range to the year 2106, would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers

Como uma última nota de rodapé, esteja ciente de que um sistema pode não ter conformidade com o y2k38 tanto no sistema / código do sistema operacional quanto no relógio do RTC.

No nível do sistema operacional, indo para um linux de 64 bits (se a arquitetura permitir), ele será corrigido agora ou, se tudo correr bem, o Linux de 32 bits corrigirá isso em um futuro próximo.

Quanto ao RTC em máquinas antigas, isso significa que você obterá dados confusos após 2038, pelo menos em logs, até que o ntpd seja ativado e corrija a data do sistema.