우분투 서버는 한 번에 정확히 5 분을 잃습니다.

3

우분투 서버 12.04 인 내 서버에서 시간을 잃는 것을 발견했습니다. CMOS 배터리에 결함이있어 하드웨어 시계가 꺼져 있거나 죽어가는 것을 알았습니다. 드리프트가 수정 될 수 있도록 NTP를 설치했지만 아무 소용이 없습니다. 하루 동안 20 분 정도 손실됩니다.

디버깅하기 위해 원격 서버 시간을 확인하는 작은 크론 작업을 만들었습니다. 스크립트는 현지 시간과 원격 시간의 차이를 초 단위로 계산합니다. 이 테스트 중에 NTP 서비스가 실행되고 있지 않았습니다 .

결과는 흥미로웠다. 하루 동안 정확히 5 분 동안 여러 번지는 것 같습니다. 이 로그를보십시오 (초 단위로 표시된 원격 서버와의 차이).

Tue Oct 23 03:30:02 CEST 2012: 284
Tue Oct 23 03:35:02 CEST 2012: 284
Tue Oct 23 03:40:01 CEST 2012: 285
Tue Oct 23 03:45:02 CEST 2012: 285
Tue Oct 23 03:50:02 CEST 2012: 285
Tue Oct 23 03:55:02 CEST 2012: 284
Tue Oct 23 04:00:02 CEST 2012: 284
Tue Oct 23 04:05:01 CEST 2012: 285
Tue Oct 23 04:10:01 CEST 2012: 285
Tue Oct 23 04:15:02 CEST 2012: 585
Tue Oct 23 04:20:02 CEST 2012: 584
Tue Oct 23 04:25:02 CEST 2012: 584
Tue Oct 23 04:30:02 CEST 2012: 584
Tue Oct 23 04:35:01 CEST 2012: 585
Tue Oct 23 04:40:01 CEST 2012: 585
Tue Oct 23 04:45:02 CEST 2012: 585
Tue Oct 23 04:50:02 CEST 2012: 584
Tue Oct 23 04:55:02 CEST 2012: 584
Tue Oct 23 05:00:02 CEST 2012: 584
Tue Oct 23 05:05:01 CEST 2012: 585
Tue Oct 23 05:10:01 CEST 2012: 585
Tue Oct 23 05:15:02 CEST 2012: 585
Tue Oct 23 05:20:02 CEST 2012: 584
Tue Oct 23 05:25:02 CEST 2012: 584
Tue Oct 23 05:30:02 CEST 2012: 584
Tue Oct 23 05:35:01 CEST 2012: 585
Tue Oct 23 05:40:01 CEST 2012: 585
Tue Oct 23 05:45:02 CEST 2012: 584
Tue Oct 23 05:50:02 CEST 2012: 584
Tue Oct 23 05:55:02 CEST 2012: 584
Tue Oct 23 06:00:02 CEST 2012: 584
Tue Oct 23 06:05:03 CEST 2012: 584
Tue Oct 23 06:10:02 CEST 2012: 584
Tue Oct 23 06:15:01 CEST 2012: 585
Tue Oct 23 06:20:02 CEST 2012: 584
Tue Oct 23 06:25:02 CEST 2012: 584
Tue Oct 23 06:30:02 CEST 2012: 584
Tue Oct 23 06:35:02 CEST 2012: 584
Tue Oct 23 06:40:02 CEST 2012: 584
Tue Oct 23 06:45:01 CEST 2012: 585
Tue Oct 23 06:50:02 CEST 2012: 584
Tue Oct 23 06:55:01 CEST 2012: 585
Tue Oct 23 07:00:02 CEST 2012: 584
Tue Oct 23 07:05:02 CEST 2012: 584
Tue Oct 23 07:10:02 CEST 2012: 584
Tue Oct 23 07:15:02 CEST 2012: 584
Tue Oct 23 07:20:02 CEST 2012: 584
Tue Oct 23 07:25:02 CEST 2012: 584
Tue Oct 23 07:30:01 CEST 2012: 585
Tue Oct 23 07:35:02 CEST 2012: 584
Tue Oct 23 07:40:02 CEST 2012: 584
Tue Oct 23 07:45:02 CEST 2012: 584
Tue Oct 23 07:50:02 CEST 2012: 584
Tue Oct 23 07:55:02 CEST 2012: 584
Tue Oct 23 08:00:01 CEST 2012: 585
Tue Oct 23 08:05:02 CEST 2012: 584
Tue Oct 23 08:10:02 CEST 2012: 584
Tue Oct 23 08:15:02 CEST 2012: 584
Tue Oct 23 08:20:02 CEST 2012: 584
Tue Oct 23 08:25:02 CEST 2012: 584
Tue Oct 23 08:30:01 CEST 2012: 585
Tue Oct 23 08:35:02 CEST 2012: 584
Tue Oct 23 08:40:02 CEST 2012: 584
Tue Oct 23 08:45:02 CEST 2012: 584
Tue Oct 23 08:50:02 CEST 2012: 584
Tue Oct 23 08:55:02 CEST 2012: 584
Tue Oct 23 09:00:02 CEST 2012: 584
Tue Oct 23 09:05:03 CEST 2012: 584
Tue Oct 23 09:10:02 CEST 2012: 584
Tue Oct 23 09:15:02 CEST 2012: 584
Tue Oct 23 09:20:02 CEST 2012: 584
Tue Oct 23 09:25:02 CEST 2012: 584
Tue Oct 23 09:30:01 CEST 2012: 584
Tue Oct 23 09:35:02 CEST 2012: 584
Tue Oct 23 09:40:02 CEST 2012: 584
Tue Oct 23 09:45:02 CEST 2012: 584
Tue Oct 23 09:50:02 CEST 2012: 584
Tue Oct 23 09:55:02 CEST 2012: 584
Tue Oct 23 10:00:01 CEST 2012: 584
Tue Oct 23 10:05:02 CEST 2012: 584
Tue Oct 23 10:10:07 CEST 2012: 584
Tue Oct 23 10:15:02 CEST 2012: 584
Tue Oct 23 10:20:02 CEST 2012: 884
Tue Oct 23 10:25:02 CEST 2012: 884
Tue Oct 23 10:30:02 CEST 2012: 883
Tue Oct 23 10:35:01 CEST 2012: 884
Tue Oct 23 10:40:02 CEST 2012: 884
Tue Oct 23 10:45:02 CEST 2012: 884
Tue Oct 23 10:50:02 CEST 2012: 884
Tue Oct 23 10:55:02 CEST 2012: 1184
Tue Oct 23 11:00:02 CEST 2012: 1183
Tue Oct 23 11:05:01 CEST 2012: 1184
Tue Oct 23 11:10:02 CEST 2012: 1184
Tue Oct 23 11:15:02 CEST 2012: 1184
Tue Oct 23 11:20:02 CEST 2012: 1184

내 생각에 이것은 CMOS 배터리에 결함이없는 것 같습니다. 하지만 어떻게 생각하세요?

편집하다:

NTP를 활성화하면 ntpq -p의 출력입니다.

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
dns02.wsrs.net  .INIT.          16 u    -   64    0    0.000    0.000   0.000
brick.steinhoff 71.40.128.157    3 u    1   64    1  144.031  1499785   0.002
chime6.surfnet. .PPS.            1 u    -   64    1   22.663  1499789   0.002
ntp0.mediamatic .INIT.          16 u    -   64    0    0.000    0.000   0.002
europium.canoni .INIT.          16 u    -   64    0    0.000    0.000   0.002

편집 2 :

ntpdate 후 ntp.ubuntu.com

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
kvm01.roethof.n 213.154.236.182  3 u   10   64    1   34.918   -1.980   0.002
ntp0.bbactive.e 193.79.237.14    2 u    9   64    1   58.378    6.956   0.002
16-164-ftth.ons 193.79.237.14    2 u    8   64    1   30.202    5.697   0.002
kameli.miuku.ne 62.237.86.238    2 u    7   64    1  106.975   -9.806   0.002
europium.canoni 193.79.237.14    2 u    6   64    1   42.010    6.381   0.002
linux  ubuntu-12.04  date-time  clock 
— 해롤드 스미스
소스
1
그러나 ntpq -psyslog에는 무엇이 무엇이고 NTP 레코드는 무엇입니까? AFAIK CMOS 클록은 일반적으로 부팅시에만 문의됩니다.
— RedGrittyBrick
테스트 목적으로 NTP를 비활성화했습니다. 방금 활성화를 시도하고 그에 따라 답변을 업데이트했습니다.
— 해롤드 스미스
a) ntp가 동기화를 시도하기 전에 시간 (1499785 ms)의 큰 오류를 수정해야합니다 ntpdate. 먼저 시도하십시오 . b) 몇 초 이상 기다려야합니다.
— RedGrittyBrick
내가 말했듯이 NTP가 실행 중이지만 때로는 300 초가 걸리기도합니다. 이런 일이 정기적으로 일어나면 NTP 동기화도 망가질 것입니다.
— 해롤드 스미스
NTP는 큰 점프를하는 것이 아니라 돌리는 시간에 의해 작동합니다 (1 초 오프셋을 수정하는 데 2000 년대가 걸릴 수 있음). NTP가 실행되고 있다고해서 NTP가 큰 시간 오프셋을 즉시 수정할 수있는 것은 아닙니다. 사용하십시오 ntpdate. NTP는 syslog에서 타임 키핑 이상을 유용하게보고합니다.
— RedGrittyBrick

답변:

2

CMOS 배터리에 결함이있어 하드웨어 시계가 꺼져 있거나 죽어가는 것을 알았습니다.

CMOS 클럭은 운영 체제를 부팅 할 때만 읽습니다.

드리프트가 수정 될 수 있도록 NTP를 설치했지만 아무 소용이 없습니다.

NTP는 큰 오프셋을 수정하기위한 것이 아닙니다. 을 사용하여 수정 ntpdate한 다음 ntpd를 시작하고 몇 시간 후에 확인 ntpq -p하고 알려주는 내용을 이해해야합니다. 그런 다음 syslog에서 NTP 불만을 찾으십시오.

NTP가 실행 중이지만 때로는 300 초가 빠지는 경우가 있습니다.

그렇다면 syslog에 NTP 주석이 표시 될 것으로 예상됩니다. 문제가 발생한시기를 정확하게 알려줍니다. 아마도 이것은 cron 작업이나 외부 이벤트와 일치합니다. 나는 그런 단서를 추적 할 것이다. 하드웨어 오류로 인해 한 번에 5 분 동안 시스템이 정지되고 있는지 알 수 있다고 가정합니다.

NTP 문제 해결

NTP 문제 해결, 특히 "알려진 문제"섹션을 읽었습니다 .

모니터링 시간

해롤드는 이미 대본을 가지고 있으며 다른 사람들에게는 여기 몇 가지 아이디어가 있습니다.

불량 서버에서 RFC868 시간 프로토콜 사용

vi /etc/xinetd.d/time-stream
# change `disable=yes` to `disable=no`
kill -HUP $(cat /var/run/xinetd.pid)

goodserver에서 cron을 사용하여 1 분에 한 번 예약

date -u; TZ=utc rdate badserver > /tmp/badserver-time.log

또는 더 나은 응답으로 실패한 서버 만 기록하거나 goodserver와 badserver 간 오프셋의 큰 변경 사항 만 기록하는 스크립트를 작성하십시오.

— RedGrittyBrick
소스
NTP 서비스를 시작하기 전에 항상 ntpdate를 실행해야하므로 처음부터 시간이 정확하다고 확신합니다. 여기에서 무슨 일이 일어나 든 NTP 서비스는 서비스 실행 여부에 관계없이 발생합니다. 그래도 syslog를 주시하겠습니다.
— 해롤드 스미스
NTP 데몬이 작동하고 날짜가 정확합니다. 다음에 syslog를 살펴 보겠습니다. SSH를 통해서만 컴퓨터에서 작업하고 있으며 불행히도 Wi-Fi를 통해서만 작업하고 있습니다. 연결이 때때로 끊어 졌기 때문에 실제로 (시스템 정지시) 동시에 발생할 수 있습니다. 나는 이것을 확인하려고 노력할 것이다.
— 해롤드 스미스
18시 27 분 (UTC + 2)에 Wi-Fi SSH 연결이 다른 모든 웹 서비스와 함께 정확히 300 초 동안 나가고 18시 32 분에 다시 로그인 할 수있었습니다. 낙진 중에 시스템 시계가 업데이트되지 않았습니다. 이것은 훨씬 더 큰 문제입니다. 3-4 시간마다 300 초의 낙진을 일으키는 원인은 무엇입니까?
— 해롤드 스미스
그래, 그리고 시스템 고장 중에도 아무것도 기록되지 않았다 ...
— Harold Smith
사나운 추측 : 비정상적이고 비정상적인 주변 장치와 나쁜 드라이버. 범인이 발견 될 때까지 비 필수 주변 장치 및 서비스를 점진적으로 제거하는 것이 좋습니다. 행운을 빕니다.
— RedGrittyBrick
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.