☰

로케일과 시간대는 정확하지만 하드웨어 및 시스템 시계는 부팅할 때마다 약 7분씩 오프셋됩니다.

tag-icon • tag-icon linux timezone clock
로케일과 시간대는 정확하지만 하드웨어 및 시스템 시계는 부팅할 때마다 약 7분씩 오프셋됩니다.

아치를 시작할 때마다 시간이 몇 분씩 늦어지는 것을 느낍니다. RTC 시간은 꺼져 있으며(내가 아는 한 "드리프트"되었습니다.) 하드웨어 시계에 영향을 미칩니다.

$ timedatectl status
                      Local time: Mo 2018-02-12 12:45:18 CET
                  Universal time: Mo 2018-02-12 11:45:18 UTC
                        RTC time: Mo 2018-02-12 11:45:18
                       Time zone: Europe/Berlin (CET, +0100)
       System clock synchronized: no
systemd-timesyncd.service active: no
                 RTC in local TZ: no

편집하다이 글을 쓰는 동안 저는 이 선 위의 시간 값이 다른 선과 일치한다는 사실을 깨닫지 못했습니다. 하지만 내 시계와 스마트폰 시간에는 앞서 언급한 7분이라는 오프셋이 있습니다.

내 로케일:

$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_PAPER="de_DE.utf8"
LC_NAME="de_DE.utf8"
LC_ADDRESS="de_DE.utf8"
LC_TELEPHONE="de_DE.utf8"
LC_MEASUREMENT="de_DE.utf8"
LC_IDENTIFICATION="de_DE.utf8"
LC_ALL=

지금까지 나는 hwclock --hctosys매뉴얼 페이지의 내용을 사용하기를 매우 꺼려했습니다.

실행 중인 시스템에서는 이 기능을 사용하지 마십시오. 시스템 시간을 건너뛰면 파일 시스템 타임스탬프가 손상되는 등의 문제가 발생할 수 있습니다. 또한 NTP의 "11분 모드"와 같이 하드웨어 시계가 변경되면 --hctosys는 드리프트 보상을 포함하여 시간을 잘못 설정합니다.

내가 아는 한,Windows 10을 올바르게 구성했습니다.. 뭔가 빠졌나요? 아니면 시계를 올바르게 설정하지 않았나요?

편집 2요청 시 콘텐츠 /etc/ntp.conf:

# Please consider joining the pool:
#
#     http://www.pool.ntp.org/join.html
#
# For additional information see:
# - https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon
# - http://support.ntp.org/bin/view/Support/GettingStarted
# - the ntp.conf man page

# Associate to Arch's NTP pool
server 0.arch.pool.ntp.org
server 1.arch.pool.ntp.org
server 2.arch.pool.ntp.org
server 3.arch.pool.ntp.org

# By default, the server allows:
# - all queries from the local host
# - only time queries from remote hosts, protected by rate limiting and kod
restrict default kod limited nomodify nopeer noquery notrap
restrict 127.0.0.1
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntp.drift

답변1

실제 시간과 시작 시 RTC 간의 시간 차이가 큰 경우 NTP는 시간이 지남에 따라 천천히 증분하는 대신 시작 후 한 번에 모두 초과 보상하도록 구성할 수 있습니다.

파일 에 첫 번째 줄을 추가하겠습니다 /etc/ntp.conf(첫 번째 줄이어야 합니다).

tinker panic 0

Tinker Panic - 패닉 임계값을 초 단위로 지정하며 기본값은 1000초입니다. 0으로 설정하면 패닉 온전성 검사가 비활성화되고 모든 값의 클럭 오프셋이 허용됩니다.

이렇게 하면 현재 Linux 시간 문제가 해결될 수 있지만 시간이 지남에 따라 두 운영 체제 간의 시간 차이가 발생하는 근본 원인도 조사하겠습니다.

답변2

명령에서 timedatectl"세계시"(즉, 커널의 UTC 개념)와 "RTC 시간"이 동기화되었다고 보고하므로 실시간 시계는 UTC 시간이며 부팅 시 시간이 RTC에서 커널 시계로 성공적으로 전송되었습니다. 시간.

그러나 그것이 사실임 System clock synchronized: no을 보여줍니다.ntpd아니요동기화가 성공한 이유는 실제 UTC가 시스템에서 가정한 UTC와 너무 다르기 때문일 수 있습니다. Rui F. Ribeiro의 답변은 이 문제를 해결하는 것을 목표로 합니다.

이 파일의 내용을 확인해야 합니다 /etc/adjtime. 첫 번째 줄에는 공백으로 구분된 세 개의 값이 포함되어야 합니다. 첫 번째는 하루에 초 단위로 배터리 구동 RTC의 가정된 시스템 드리프트 속도입니다. 두 번째 값은 가장 최근의 RTC 드리프트 조정 시간의 UNIX 타임스탬프입니다.

드리프트 속도가 잘못 큰 경우(아마도 RTC가 런타임 시 다른 운영 체제에 의해 조정되고 RTC 드리프트로 잘못 감지되었기 때문일 수 있음) 시작 시 7분 오류가 발생할 수 있습니다.

배터리 지원 RTC에서 코어 클럭으로 시간을 복사할 때 시작 시 드리프트 속도 수정이 적용되므로 잘못된 드리프트 속도로 인해 발생한 오류도 코어 클럭으로 전파될 수 있습니다. 이는 두 시계가 서로 동기화되어 있지만 실제 UTC에서 7분 차이가 나는 이유를 설명합니다. 이는 또한 달리기가 hwclock --hctosys문제를 해결하지 못한다는 것을 의미합니다.

드리프트 속도가 /etc/adjtime비정상적으로 큰 경우 잘못된 드리프트 속도 수정으로 인해 시계가 조정되는 것을 방지하기 위해 이를 0으로 설정하거나 전체 파일을 지워야 합니다. 시스템 시계가 NTP와 동기화되는 경우 일반적으로 배터리 지원 RTC에도 동기화 시간이 전파됩니다.

"콜드" 드리프트 비율(즉, 시스템이 꺼져 있거나 다른 운영 체제를 실행할 때 발생하는 드리프트)에 대한 자동 보상을 설정하려면 /etc/adjtime다음 절차를 사용할 수 있습니다.

1.) 시작 및 종료 스크립트를 확인하여 시스템 시계 또는 배터리 지원 RTC가 실행되는 모든 지점을 이해했는지 확인하십시오.

2.) 비교적 긴 시스템 가동 중지 시간(최소 4시간, 밤새 또는 주말이 더 좋음)을 선택하십시오. 그런 다음 모든 자동 NTP 동기화를 일시적으로 비활성화합니다. initramfs 스크립트도 포함되어 있는지 확인하세요.

3.) 시스템을 종료하기 전에 시스템 시계의 시간이 올바른지 확인한 후 실행하십시오 > /etc/adjtime; hwclock --systohc --utc --update-drift. /etc/adjtimenow가 0.0첫 번째 행의 첫 번째 값이고, 현재 Unix 타임스탬프가 첫 번째 행의 두 번째 값이고 +가 두 번째 행의 유일한 값이고, 세 번째 행이 표시되는지 확인합니다 UTC. 그런 다음 시스템을 종료합니다.

4.) 시스템을 다시 시작한 후 ntpdate또는 다른 방법을 사용하십시오.코어 클럭만 설정시스템이 정확한 UTC 시간을 얻도록 하십시오. 그런 다음 다시 실행하십시오 hwclock --systohc --utc --update-drift. 이제 첫 번째 값은 /etc/adjtime시스템이 다운될 때 RTC가 표류하는 속도와 일치하도록 업데이트되어야 합니다 .

5.) 그런 다음 NTP 동기화 시스템에서 자동으로 실행되는 시작/중지/크론 작업이 없는지 확인하십시오. 다음과 hwclock --update-drift같은 경우에만 드리프트 속도를 업데이트하면 됩니다.확실히 알아라드리프트율 추정에 사용한 기간 동안 RTC를 조정할 수 있는 것은 없습니다.

6.) 마지막으로 NTP 동기화를 다시 활성화합니다. 두 개 이상의 운영 체제로 이중 부팅하는 경우 이상적으로는 하나의 운영 체제만 RTC를 조정해야 합니다. 그렇지 않으면 드리프트 속도 추정이 부정확해집니다.

답변3

최근 Linux 커널을 확인하지 않았지만 이전 커널에는 시스템 시간(RAM)에서 RTC를 업데이트하는 매우 이상한 코드가 있습니다. 나는 수년 전에 이 문제를 해결하려고 노력했지만 코드가 커널에 포함되지 않았습니다.

현재 시스템은 종료 또는 재부팅(활성화된 경우) 시 시스템 시간부터 RTC를 업데이트한다고 생각합니다.

배포판에서 메커니즘을 제공하지 않는 경우 cron 작업(또는 systemd타이머)을 추가하여 RTC를 주기적으로 업데이트할 수 있습니다.

관련 정보