네트워크 시간과 동기화하기 위해 매일 실행되는 /etc/cron.daily/ntpupdate
시스템 파일이 있다고 생각합니다 .ntpdate ntp.ubuntu.com
매일 다음과 매우 유사한 출력이 생성됩니다.
/etc/cron.daily/ntpupdate:
16 Jan 06:30:42 ntpdate[21446]:
step time server 91.189.94.4 offset -12.646804 sec
이것이 무엇을 의미하는지 잘 모르겠지만 , 서버가 약 12초 동안 다운되었다는 의미인 것은 91.189.94.4
확실합니다 . -12.646804 sec
그런데 왜 매일 같은 양만큼 감소하는지 모르겠습니다. Ubuntu를 실행하는 Amazon EC2 인스턴스입니다.
나는 그것이 매일 12초 더 느리거나 더 빠르거나 다른 것이 12초 더 느린 다른 시계와 시간을 동기화하고 있다고 추측할 수 있으며 다시 동기화합니다.
이 문제를 더 자세히 추적하려면 어떻게 해야 합니까? /etc/cron.*
디렉토리에 다른 크론 작업이나 사용자의 크론 작업이 표시되지 않습니다 .
고쳐 쓰다
특정 시간에 큰 상승이 있는지 확인하기 위해 매시간 실행하기 시작했다는 사실을 공유하고 싶다고 생각했습니다. 시간당 출력은 다음과 같습니다.
16 Jan 15:17:04 ntpdate[8346]:
adjust time server 91.189.94.4 offset -0.464418 sec
따라서 시계는 매 시간마다 약 0.5초씩 어긋나므로 하루(24시간)에 약 12초씩 어긋나는 것이 합리적입니다. 시계가 너무 빨리 가는 것 같아요! 감사해요!
答え1
소프트웨어 시계가 느리게 또는 빠르게 실행되는 원인은 여러 가지가 있습니다. 가상 서버의 시계는 특히 이러한 유형의 문제에 취약합니다. 시계가 180-200%로 작동하는 가상 상자에 도달하기 전까지는 하루 12초는 꽤 나쁜 시간입니다! 정지된 노트북의 시계에도 타이밍 문제가 발생할 수 있습니다.
ntupdate
지원 중단을 고려해야 합니다 ntpd
. 패키지 이름은 ntp
Debian(그리고 아마도 Ubuntu도)에 있습니다. NTP 데몬은 cron 작업보다 더 적극적으로 시간 동기화를 유지하여 하나 이상의 다른 NTP 서버와 동기화하고 시계를 더 정확하게 만듭니다. 이는 시간이 지속적으로 모니터링된다는 ntpdate
점을 제외하면 동일한 프로토콜에서 사용되는 또 다른 구현 입니다 .ntpd
(매우 작은) 오버헤드를 원하지 않으면 매시간 실행하는 것을 ntpd
고려할 수 있습니다 . ntpdate
매 시간 0.5초의 휴식 시간을 가정하면 이 정도면 충분합니다.
答え2
귀하의 질문의 나머지 절반에 대해 답하자면, 이것이 바로 이런 일이 발생하는 이유입니다. 컴퓨터 하드웨어 시계는 부정확하기로 악명 높기 때문에 하루에 12초의 편차가 흔하지는 않지만 실제로는 그렇게 특이한 것은 아닙니다.
(이것은 아마도 네트워크 시간 사용이 일반적이기 때문에 매일 12초의 드리프트도 시계에서 발생하는 것과 비교하면 아무것도 아닙니다. 따라서 하드웨어 회사는 값싼 시계 칩을 사용할 수 있습니다. 물리적으로 무슨 일이 일어나고 있는지 시계의 발진기가 원인일 수 있습니다. 칩이 제대로 보정되지 않아 약간 느리게 실행되지만 실제로는 느립니다.)
答え3
차이가 너무 작기 때문에 ntp가 서버 시간을 업데이트하지 않을 것 같습니다. 비슷한 문제가 있었는데, 특정 임계값이 발생할 때까지 ntp가 업데이트되지 않는 약간의 차이를 발견할 때까지 매일 동일한 지연이 발생했습니다.
동기화를 위한 최소 임계값 구성을 확인하세요.