시스템이 2038년 이후의 날짜를 설정하면 ntpdate가 실패합니다.

시스템이 2038년 이후의 날짜를 설정하면 ntpdate가 실패합니다.

현재 정확한 날짜는 2016년 5월 25일 금요일 12:11:07 CST입니다.

날짜를 "2018/01/01"로 변경하면 ntpdate가 제대로 작동합니다.

날짜를 "로 변경하면2099/01/01", ntpdate가 제대로 작동하지 않습니다.

좋아요:

[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

안좋다:

[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

5월 1일 월요일 18:41:18 CST 2152가 잘못된 날짜입니다.

ntpdate유효한 범위가 있습니까?

답변1

먼저 몇 가지 참고 사항:

  • NTP의 현재 버전(v4)시대를 사용하여 작동하십시오.

  • 에포크는 136년(부호 없는 32비트 정수로 표시되는 초 수)입니다. 아니면 대충

      60 * 60 * 24 * 365 * 136 = 4288896000 
                          2^32 = 4294967296
    
      4294967296 − 4288896000 = 6071296
       6071296 / 60 / 60 ∕ 24 ≈ 70 (days, not accounting for leaps)
    
  • 0시대:이것황금시대또는 기준일"0시대", 이는 1900년 1월 1일 00:00 UTC 시간입니다.

  • 시대 1:2036년 초부터 시작됩니다. (UNIX-2038 2년 전)

  • 시대 2:이야기는 2172년 초에 시작됩니다.

  • 등. (다른 예를 보려면 다음을 확인하세요.RFC 5905 14페이지.)

  • ntpdate64비트 NTP 타임스탬프를 사용합니다. 초는 32비트이고 분수는 32비트입니다.

  • 아마도 약간 혼란스러울 수 있습니다. NTP-date는 128비트를 사용하고 시대를 포함합니다. 이는 우주의 나이에 걸쳐 먼 미래까지 확장됩니다.

에서 언급했듯이NTP 부분의"2038년 문제" - 위키피디아 페이지넌 절대적인 한계가 있어68세두 NTP 타임스탬프 사이. ( 136 / 2 = 68). 그러나 모호성을 제거하려면 더 좁은 주파수 대역을 사용해야 합니다.

NTP 타임스탬프는 절대 시간이 아닌 상대 시간을 기준으로 작동합니다. 서버는 자체 시간의 상대 오프셋을 통해 클라이언트에 수정 사항을 제공합니다. 즉, 다음과 같이 말하지 않습니다:

—2016년 3월 26일자

대신(NTP 작동 방식으로 단순화됨):

— 당신은 +123412512.918초 뒤쳐져 있습니다, 또는:
— 당신은 -2652221.3466초 뒤쳐져 있습니다, 등.

또는 RFC에서 인용하십시오.

타임스탬프는 부호 없는 값이며 이에 대한 작업은 동일하거나 인접한 에포크의 결과를 생성합니다. Epoch 0에는 주요 시대부터 타임스탬프 필드가 순환되어 Epoch 1의 기본 날짜를 설정하는 2036년 특정 시점까지의 날짜가 포함됩니다.

귀하의 연도가 2099년이면 귀하는 이미 68년 이상, 즉 약 15년 ​​후입니다. 당신은 2152년에 끝나고 우리가 얻는 것은 다음과 같습니다:

 2152 - 2016 = 136 (One era)

아니면 다른 말로 표현하면:

                    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)

네, 귀하의 질문에 대답하자면 다음과 같습니다.

—— ntpdate유효 범위가 있나요?

예. ± 68세, 하지만최대 유효 범위조금 좁습니다.

NTP 자체는 무제한입니다.

구경하다RFC 5905관심이 있다면. 또한 오래된 RFC에는 흥미로운 정보가 포함될 수 있습니다.부록 E. NTP 시간 척도 및 타이밍 방법 RFC 1305에서.


(부착: UNIX 타임스탬프와 비교하면 1970 + 68 = 2038.)

답변2

여러분이 보고 있는 것은 2038년 문제, 즉 Y2K38 버그라는 일반적인 "버그"로, 32비트 Linux 서버에 여전히 존재합니다.

2000년쯤에 우리는 2000년/천년 오류 외에도 미래에 또 다른 시간 관련 오류가 있을 것이라는 것을 깨달았습니다. (예, 저는 Y2K "예방" 팀의 일원이었습니다)

Unix epoch는 1970년 1월 1일에 시작된 32비트 초 카운터이고 단지 부호 있는 32비트 정수이기 때문에 표준 표준에서는 03:14:07로 제한되었습니다(일부 시스템에서는 여전히 사용 가능). 때는 2038년 1월 19일.https://en.wikipedia.org/wiki/Year_2038_problem

최신 구현에서는 64비트로 확장되었습니다.

NetBSD 버전 6.0(2012년 10월 출시)부터 NetBSD 운영 체제는 32비트 및 64비트 아키텍처 모두에 64비트 time_t를 사용합니다. 32비트 time_t를 사용하는 이전 NetBSD 버전용으로 컴파일된 응용 프로그램은 바이너리 호환성 계층을 통해 지원되지만 이러한 이전 응용 프로그램은 여전히 ​​2038년 문제의 영향을 받습니다. [13]

2014년 5월에 출시된 버전 5.5부터 OpenBSD도 32비트 및 64비트 아키텍처에 64비트 time_t를 사용합니다. NetBSD와 비교하면 바이너리 호환성 계층이 없습니다. 따라서 32비트 time_t를 기대하는 애플리케이션과 time_t와 다른 것을 사용하여 시간 값을 저장하는 애플리케이션이 충돌할 수 있습니다. [14]

Linux는 이전 버전과의 호환성으로 인해 64비트 아키텍처에 대해 64비트 time_t만 사용하며 순수 32비트 ABI는 변경되지 않습니다. [15] 현재 진행 중인 작업은 32비트 아키텍처에서 64비트 time_t를 지원하는 임베디드 Linux 시스템에 중점을 두고 있습니다.

민속 역사의 일부이자 다소 정교한 사기인 John Titor는 2038년에 미래의 유산을 바로잡는 데 도움이 되는 메인프레임을 획득하기 위해 시간을 거슬러 보내졌으며 힐러리 클린턴(Hillary Clinton)의 지휘하에 2038년 미국 남북 전쟁/핵 전쟁이 일어날 것이라고 예측했습니다. 우리의 평행 현실.

http://www.strangerdimensions.com/2011/10/03/john-titor-the-ibm-5100/

존 티토의 이야기는 2036년에 시작됩니다. Titor는 시간 여행을 시작하기 위해 선택된 7명으로 구성된 팀의 일원입니다. 그는 이기적이고 냉소적이며 부패한 정부에 의해 파괴되고 핵전쟁으로 황폐화된 세계에서 상상할 수 없는 공포를 경험합니다. 설상가상으로 남은 기술은 2038년에 발생할 수 있는 UNIX 시간 초과 오류로 인해 위협을 받고 있습니다.

또한 참조하시기 바랍니다https://en.wikipedia.org/wiki/9223372036854775807

32비트 유형을 사용하는 시스템은 2038년 문제에 취약하므로 많은 구현이 더 넓은 64비트 유형으로 이동했으며 최대값은 지금으로부터 2920억년 지점에 해당하는 263−1입니다.

그럼 다시 ntpdate 질문으로 돌아가겠습니다.

2038년 한계에 대해서. 따라서 문제는 time_t가 32비트 부호 있는 정수라는 것입니다. 즉, 32비트 정수이며 마지막 비트는 신호 전용입니다. 따라서 실제로는 숫자(-0x7fffffff와 +7ffffffff(+2147483647) 사이의 초 수만 저장할 수 있습니다. 따라서 +2147483647은 1970년 1월 1일에 간격 표시를 +2147483647초로 제한합니다. 이는 ntpdate가 다음 작업만 가능함을 의미합니다. 2038년 1월 19일 03:14:07 UTC를 기준으로 시스템에 날짜를 저장합니다.

2038년 이후의 날짜와 관련하여 문제는 문자열을 내부 표현(time_t/32비트 정수)으로 변환하는 코드 루틴이 라이브러리 구현에 따라 줄바꿈하거나 단순히 일/0초로 재설정된다는 것입니다.

귀하의 모자 연도와 관련하여. 시스템의 time_t는 부호 있는 정수이므로 라이브러리는 부호 없는 정수 값으로 상한을 확인합니다. 그러면 1970년 1월 1일 이후 +4294967295초에 2106년경의 상한이 제공됩니다. 구현에 따라 검사는 실제로 문자열에서 더 많이 수행될 수 있습니다. 또는 32비트 정수의 속성으로 인해 동작이 발생하고 ntpdate 코드만 검사됩니다.

INT_MAX(32비트) = 2147483647
UINT_MAX(32비트) = 4294967295(0xffffffff)

~에서https://en.wikipedia.org/wiki/Year_2038_problem

예를 들어, time_t를 부호 없는 32비트 정수로 변경하면 범위가 2106년까지 확장되어 1970년 이전 날짜를 저장, 검색 또는 조작하는 프로그램에 부정적인 영향을 미칩니다. 이러한 날짜는 음수로 표시되기 때문입니다.

마지막 각주로, 시스템/OS 코드 및 RTC 시계에서 y2k38 규정 준수가 부족할 수 있다는 점에 유의하세요.

OS 수준에서는 64비트 Linux(아키텍처가 허용하는 경우)를 사용하면 지금 문제를 해결할 수 있으며, 32비트 Linux를 사용하면 가까운 시일 내에 문제가 해결될 것입니다.

이전 시스템의 RTC의 경우 이는 ntpd가 시작되어 시스템 날짜를 수정할 때까지 적어도 로그에서 2038년 이후 왜곡된 데이터를 받게 된다는 것을 의미합니다.

관련 정보